As previously mentioned I have been focusing on some speed tweaks for AdFind for larger scale environments. One of the items I have wanted to speed up was the decoding of Security Descriptors especially in orgs where they got a little crazy with AD Delegation and added a ton of ACEs to object Security Descriptors. I have succeeded in this space, even better than what I had hoped.
The test AD object I am performing my speed tests on had 390 ACEs and I am resolving the SIDs halfway across the USA via a “slowish” VPN connection. Resolving the SIDs for multiple objects is actually not bad because once AdFind resolves a SID it caches it for quick retrieval the next time it encounters it within that run[1].
Here are the numbers:
| VERSION | Time MS |
| V01.49.00 SIDs only | 3219 |
| V01.50.00 SIDs only | 3078 |
| V01.49.00 Resolve SIDs | 75296 |
| V01.50.00 Resolve SIDs (initial) | 35719 |
| V01.49.00 Resolve SIDs | 75296 |
| V01.50.00 Resolve SIDs (enhanced) | 4250 |
Yes you are reading that right, Security Descriptor expansion with SID Resolution reduced from 75.3 seconds to 35.72 seconds to 4.25 seconds.
I am expecting to wrap up a zip file with the V01.50.00 Beta in the next week with a special download location. If you are interested, stay tuned. 
joe
[1] I have long considered adding some persistence for SID caching but I haven’t thought about it enough to pull the trigger yet.
SID Caching is necessary for Foreign Security Principals – where do you store the ADfind application cache?
I am not sure I understand the statement that SID Caching is necessary for Foreign Security Principals. Can you give more detail?
As for where is the app cache for AdFind, it is in memory during the runtime and is built for every new run instance when a SID is encountered and needs to be resolved. That is what I was saying when I mentioned that I have “considered” a persistent cache.
joe