This is a great solution and an obvious benefit of AD/AM.

Alternatively if you have to use AD. Look at setting up an ipsec policy you
can turn on and off to block 389 or 3268 or whatever port you are talking to
AD on. 

Alternatively as Gil said, pull the cable when running it on another
machine.

Note though that you may get different responses in your program from idle
time drop and a forced disconnect due to service dying or port blocking on
the server. 


Maybe being nitpicky, but I don't consider any app that blows up due to a
understandable and expected event very solid, though it could be functional.
This falls solidly within the bounds of

"Beware of bugs in the above code; I have only proved it correct, not tried
it." [1]

in my honest opinion. Any network program or if you prefer any client/server
program has to have some form of consideration concerning losing
connectivity. It will happen, it isn't a matter of if, but when. If this app
is doing anything security related that is especially true. I have seen very
poor code that always assumes the network call goes through and they are
simply looking for a specific error returned saying the password wasn't
valid. If it didn't see that error, it was assumed that things were good. I
expect this may be a good time to go through your app and look at every call
dependent on an external event and say, how would this fail if this call
could not properly execute? What exceptions can be thrown by the classes I
am dependent on and do I have consideration for that in my programs? Pay
particular attention to anything that could cause security issues or data
issues. Failing back to the OS can be a perfectly acceptable handling of an
error (i.e. Check for success, if not successful float returned error info
up to the surface and exit gracefully - I often do this for my tools). Doing
nothing can also be an acceptable handling but it should be explicit in the
code, i.e. If this error, do nothing. This way, it is captured in the code
that you have forecast that error and do not see it to be a threat. This
could change on a further change in the code and seeing that handling may
cause someone to think twice as to whether it isn't a threat anymore when
they make a change.

  joe



[1] Donald Knuth

 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: Friday, February 04, 2005 8:23 PM
To: [email protected]
Subject: RE: [ActiveDir] Stop AD service?

Or if you can repro the bug with ADAM (assuming your app work sthere), that
can be stopped/started on the fly.

~Eric


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick
Sent: Friday, February 04, 2005 5:57 PM
To: [email protected]
Subject: RE: [ActiveDir] Stop AD service?

AD can't be shut down per se; in fact, if AD crashes for some reason, it
will shut down the machine automatically.

Run your app on your workstation or on another server, then pull the wire.

-gil

Gil Kirpkatrick
CTO, NetPro


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Beagan, Patrick
Sent: Friday, February 04, 2005 4:53 PM
To: [email protected]
Subject: [ActiveDir] Stop AD service?

Is there a way to stop the Active Directory service?  I'm probably missing
some core concept here, but it seems to me that AD can't be
'shut down'.   I would think there would be an entry in the Services
list that allows one to stop AD.  

Here's my situation:  I've never used AD before.  I have a java app that
connects to AD to retrieve info, it is functional and solid.   After
some idle time, the connection times out resulting in a bug in my
application (exception is java.net.SocketException: Socket closed).   I
have a plan on how to fix the bug, but first I need to be able to replicate
the problem.  I need to be able to sever the connection from the Active
Directory side. 
Any ideas?  
Thanks in advance,
Patrick

List info   : http://www.activedir.org/List.aspx
List FAQ    : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Reply via email to