lithnet/ad-password-protection

why not replicate in sysvol

AmineArif1 opened this issue · 5 comments

Hello!

I apologize if this isn't the appropriate place for my query, as it's not exactly an issue but rather a question. I've noticed in the documentation a recommendation against using SYSVOL to store the blacklist. This caught my attention because, in contrast, Microsoft's password protection strategy involves storing password policies, which include the blacklist, within the SYSVOL folder. Could you provide some insight into the reasoning behind this advice?
image

Thank you!

Our store can be many gigabytes in size and contain billions of passwords and banned words.

Microsoft policy and banned word blacklist is tiny. You can have only 1000 words from memory.

Sysvol is critical for the operation of AD and it's not designed as a general data store. To avoid replication issues, DC boot delays, and other issues, we recommended creating a dedicated replication group - rather than misusing sysvol just because it's there.

Also when updating the store you likely need to pause dfrs replication. Doing this on sysvol can cause inconsistency in the domain during the update period

Thank you for your swift and detailed response!

Building on that, I'm curious about the performance implications of searching through a blacklist containing billions of passwords within the AD environment. Could you elaborate on the potential consequences this might have on AD operations and overall system responsiveness?

Thank you again for your valuable insights!

The store database is built using a very efficient data structure that allows us to search the hashes with a binary search algorithm. We only need to do around 9x12 byte disk io operations per look up.

Lpp has been proven to scale in environments of hundreds of thousands of users with hundreds of millions of breached passwords without noticeable performance impacts.

LPP was written with enterprise scale, performance, and reliability as key objectives.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.