Initially, this started out as a comment, but I think I can form it into an answer for you. First, you are not really doing anything wrong, but I can point out places that your code speed could be improved.
You are joining a decent amount of tables. This will cause SQL to be slower than a single table/a few joined tables.
The
.Contains()
method corresponds toLIKE
in SQL syntax. This is slower than an actual value match (=
). You could entertain the possibility of providing drop down lists to your user for searching so that they a) don't need to know the names and b) they can quickly see the possible values."Can AD cause the slowdown" - possibly. It depends on how well your infrastructure is maintained and laid out and more on your network guys. If your AD/LDAP server is under a heavy load (because its running Exchange and SQL and DNS, etc), it can be slow in responsiveness, but this is not a code issue.
Most likely, your debugger is what is actually causing your slow down. I have noticed that EF 6 runs much slower with the debugger attached than previous versions. As noted earlier, our production app runs at around 2s in localhost and 150-200ms in release mode on a not stellar web server hardware wise.
Instead of asking AD each time, perhaps you ask once and then cache the AD results in a cookie or something similar. This would cut down on the requests outside of your app for each request.
So, in summary, no - you do not appear to be doing anything wrong. You do have room for improvement in my opinion, but I would not worry too much about it until you actually can get it on a server and out of localhost and test your application.