What about distributed data?

But Dave, in response to your comment:

"Well, no. While I didn't state it expressly, all SQL database data is left in the SQL database, with the power of it's join engine at our beck and call to select only that data which is needed for our particular problem."

I agree that the power of the SQL database engine is at our disposal. However, that power is limited when it comes to distributed queries, particular where the data exists in heteroegenous database engines. This is likely given that identity-related data is dispersed across multiple applications. Reliance on a virtual directory system, unless it has sophisticated distributed query optimisation techniques to determine the best way to move and join data, could result in significant overhead in comparison to synchronising the data into a single engine specifically designed for the purpose.
"n compute-intensive environments it might be necessary to devote a computer to servicing these join requests in tandem with the virtual directory server, but that's a time-honored (well, 10-15 years, perhaps) method of solving compute problems. The various services could even be linked through a separate backbone, or mesh, network to improve throughput both for those services as well as for all of the clients."

Of course this is true but again doesn't resolve the distributed query issues. The next logical step in your argument could be to move the data to that computer devoted to join processing - a metadirectory.

Click to read the article this is in response to.