Hi Joe,
Your point about users being expired while the synchronization /
policy enforcement service is inaccessible is quite relevant, I think.
Our default approach is to allow password changes to proceed on the DC,
with just the Win2K policy, but without the central policy also being
applied, in this case.
This basically makes the compromise of "if you can't enforce the
super-duper global policy for a while, then at least do no harm and do not
interfere with reasonable but not-necessarily-perfect password change
requests."
The idea of a local agent is not off the wall at all. Some vendors do it,
and we have toyed with the idea for years. You're quite right that putting
into the context of the LSA would be really bad. In my opinion, putting
anything heavy enough to be called a service on production DCs is not a
good idea. Our reasoning here is basically this:
* DCs are production-critical servers.
* As software grows and becomes more complex, it's increasingly
difficult to ensure that it's totally free of bugs.
* Buggy software on a DC is intolerable.
* Conclusion: install nothing, or at most very simple software, on DCs.
* Corrolary: do not install complex, stateful services on DCs.
A middle-of-the-road solution that we do support is to log failed
connections to an encrypted file (simple enough..), log the fact
that failures occurred to the event log (also trivial), and provide
a cmd-line program to flush the file into the synchronization queue.
This doesn't buy after-the-fact policy enforcement, but it does allow
administrators to clean up after a network outage, by helping users
to get their passwords back in synch.
Not perfect, but better than nothing, and does not put complex agents
on the DCs.
As for the address for royalty checks... <grin> I hope we're off the
hook by virtue of the "yeah, we thought of that already" rule. :-)
If it does come up, I do have your work e-mail address ... the one whose
md5sum comes to 9bbb45004600024ad9852123bc631280. :-)
Cheers,
-- Idan
On Sun, 7 Dec 2003, Joe wrote:
> > As such, the worst-case mode of failure is not too bad
> >(users can't change passwords until you figure out what's up).
>
> If they are expired, they are S.O.L. That is my concern. The alternative is
> to allow changes to go through in the event that contact can't be made which
> means rules aren't enforced so you are in an unknown state with the
> passwords and need to do additional work to make sure things are what they
> should be.
>
> I think a possible method would be to have a central server but have enough
> info and logic on the DC agents to allow them to operate independently for
> short periods of time and then when they can call home, let home know what
> happened when they were out of touch; it also makes the whole system more
> scaleable as you don't call back for every request. Definitely makes things
> heavier and I wouldn't put it into the LSASS plugin personally; I would add
> a local service agent that the LSASS agent chatted with. Of course then if
> you can't get to that because someone stopped it, you have another issue you
> have to figure out the correct answer for. :o)
>
> Trouble around every bend...
>
> BTW, if you want to use that local agent idea I will send you an address for
> you to mail the royalty checks... Of course you could just put me on some
> sort of retainer as well. I can come in occasionally and throw off the wall
> ideas around the room and people can stare at me like I am really strange
> and then a couple of years later say, hey didn't joe say something like that
> a couple of years ago. ;o)
>
>
> joe
>
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
