RE: Re: [ActiveDir] icmp's

2006-01-02 Thread Ulf B. Simon-Weidner








Cool  Darren is blogging.



And already in OPML-o-Matter:

http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/12/30/80015.aspx



Gruesse - Sincerely, 

Ulf B. Simon-Weidner 

 MVP-Book
Windows XP - Die Expertentipps: http://tinyurl.com/44zcz
 Weblog: http://msmvps.org/UlfBSimonWeidner
 Website: http://www.windowsserverfaq.org
 Profile:http://mvp.support.microsoft.com/profile="">











From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, January 02, 2006 2:15 AM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir] icmp's





Darren and I have had offline chats about this before so I know we
are quite in sync on our thoughts. That is one of the reasons I am brave enough
to spout them, if Darren isn't beating me up on my GPO thoughts they can't be too
far off base. He is the GPOGUY after all. :o)



http://www.gpoguy.com/



BTW, I didn't see Darren say it, but I just found today that he has
started blogging... http://blogs.dirteam.com/blogs/gpoguy/.




But back to this stuff... I agree that the common interface is
nice, but don't fully believe the info needs to be written to a policy file in
sysvol since you have the DCs right there to write the info into AD. But alas,
as you mention, we are talking decent reworkingof how things work and
that includes parts of AD to do really do it cool especially in terms of
restricted AD groups. I do believe that for some of the stuff, code is now in
there to force the change to only occur on the PDC. I am not sure when the
change occurred but I am guessing K3 but I was trying to chase some code a
month or two back in the Windows source tree and it appeared there was some
code in the GPO processing that was looking for a PDC in order to make changes.
I ran out of time and never went back to it though. 



RE the API for settings. It is kind of sad how that
wasn't/hasn't/maynotbe implemented. It seems like it would have been easiest
way for MS to have done things for themselves as well. I do agree that it is
possible to reverse it out and figure out how to do it. Of course we aren't
supposed to but that doesn't stop progress in the MS world.
Eventuallysomeone at MS will see what someone else is doing with their
tech and say hey that is pretty cool, lets dothat now. 

















From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia
Sent: Sunday, January 01, 2006 7:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir] icmp's

Random input below









From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January 01, 2006 11:54 AM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir] icmp's

Rick came out of the woodwork and rambled:



Huh? Can you explain both statements, joe?



First statement being, I would rather not set domain policies in
GPOs... I am referring to actual domain policy, not a policy applied to all
machines in the domain. You know, the original meaning of domain policy.
Pushing any policy to domain controllers that has to do with configuration of
AD is assinine in my opinion, you already have a mechanism to push those
changes through the environment. You don't need to use another one. Also it is
a point of confusion for tons and tons of people. There should be a clear
divisor between true domain policy and a policy that gets applied to each
individual machine. 
[Darren
Mar-Elia]If you're referring to using stuff like
Restricted Groups policy to control domain-based group membership, then I agree
and in fact its definitely a bad idea. The thing I don't like is that there
really isn't any decent way to remove that capability out of the box. I could
see value in using GP to control certain AD config settings, just so that you
could have a common interface for all Windows configuration settings, but GP
processing should be smart enough to say, hey, I'll only apply these domain
changes to the PDC emulator and let AD replicate them out, or something like
that. 



Second statement being programmatically handling settings in
policies... You can't set GPO settings programmatically unless you reverse the
format of the policy information in sysvol. All you can do is
backup/restore/export/import/enable/disable. What if I want to take all
policies under the OU Buildings (which could be tens, hundreds, or thousands of
policy files) and set one setting, for the sake of argument say password policy
for local machinesis equal to some set of values based on the specific OU
name that the policy is applied to (say it has finance in the name of the OU)
how will you do that programmatically without directly hacking the policy files
which last I heard wasn't supported?
[Darren
Mar-Elia]Agreed that an API into policy settings would be
great. I've only asked about 55 times and it still isn't on the horizon. Why?
Mostly because there is no standard within GP around how settings are stored.
Since separate product teams ori

RE: Re: [ActiveDir] icmp's

2006-01-02 Thread Rick Kingslan








Cool. Now I understand the rationale
for what you were getting at.



Rick











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January 01, 2006
1:54 PM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir]
icmp's





Rick came out of the woodwork and rambled:



Huh? Can you explain both
statements, joe?



First statement being, I would rather not
set domain policies in GPOs... I am referring to actual domain policy, not a
policy applied to all machines in the domain. You know, the original meaning of
domain policy. Pushing any policy to domain controllers that has to do with
configuration of AD is assinine in my opinion, you already have a mechanism to
push those changes through the environment. You don't need to use another one.
Also it is a point of confusion for tons and tons of people. There should be a
clear divisor between true domain policy and a policy that gets applied to each
individual machine. 



Second statement being programmatically
handling settings in policies... You can't set GPO settings programmatically
unless you reverse the format of the policy information in sysvol. All you can
do is backup/restore/export/import/enable/disable. What if I want to take all
policies under the OU Buildings (which could be tens, hundreds, or thousands of
policy files) and set one setting, for the sake of argument say password policy
for local machinesis equal to some set of values based on the specific OU
name that the policy is applied to (say it has finance in the name of the OU)
how will you do that programmatically without directly hacking the policy files
which last I heard wasn't supported?

















From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Sunday, January 01, 2006
1:09 PM
To: [EMAIL PROTECTED]
Subject: RE: Re: [ActiveDir]
icmp's

joe stood up and attempted to smack Mark
Parris with a large trout, saying:



I would rather not set domain
policy with GPOs. While I am at it, I think we are far beyond the point that we
should have the ability to programmatically handle settings in policies.



Huh? Can you explain both
statements, joe? I understand the context of the first, but not
why. The second  I just am not sure what youre getting
at. Help out an old haggard road warrior.



;o)



Rick











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January 01, 2006
10:50 AM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir]
icmp's





Come on, who ya going to believe?
Microsoft who has all sorts of typoes in the documentation (I just saw a
reference to objectcategory=user in an MS doc 2 days ago, I still have the
bruise on my forehead)or our trusted source... Al?



:o)



Personally I like theold style logon
scripts better than GPO logon scripts. Way too many things impact GPO
functions. I never found it difficult to write logon scripts designed to work
on specific users nor machines sodidn't need the sorting capability of
GPOs. Overall I am ok levelhappy with having a default domain GPO and
default dc GPO as the only GPOs. I would rather not set domain policy with
GPOs. While I am at it, I think we are far beyond the point that we should have
the ability to programmatically handle settings in policies. 













From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris
Sent: Sunday, January 01, 2006
9:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir]
icmp's

This is from the Microsoft article  Enterprise logon scripts



By default, logon
scripts written as either .bat or .cmd files (so-called legacy
logon scripts)
run in a visible command window; when executed, a command window open up on the
screen. To prevent a user from closing the command window (and thus terminating
the script), you can the Run legacy logon scripts
hidden enable policy. This ensures that all legacy logon scripts run
in a hidden window.



Mark











From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: 01 January 2006 14:18
To: ActiveDir@mail.activedir.org
Subject: [Norton AntiSpam] Re:
[ActiveDir] icmp's







I thought i read somewhere in some MS doc it being refered to as
legacy since now you can put multiple logon scripts in GPO's and
that they recommend doing it that way.











everytime a new OS or feature comes out, MS tends to refer to the
previous os/feature as legacy or down-level.





maybe i just made a silly assumption that using a logon script as a
user attritbute( i guess somewhat simillar to the way NT did it)instead
of a GPO was legacy.





thanks













On 1/1/06, Al
Mulnick [EMAIL PROTECTED]
wrote: 



I personally haven't heard it referred to as legacy.
I think that may be because it wasn't a legacy method when I last heard it ;)











I haven't tested this, so your mileage may vary but: the
legacy method would have been created and designed for a time
before ICMP

Re: [ActiveDir] icmp's

2006-01-01 Thread Al Mulnick
I personally haven't heard it referred to as legacy. I think that may be because it wasn't a legacy method when I last heard it ;)

I haven't tested this, so your mileage may vary but: the legacy method would have been created and designed for a time before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was disabled. Several things will break, but I don't believe that's one of them. 


Test it. You'll know for sure then right? Besides, I don't imagine alot of networks out there are configured with ICMPdisabled like that.

Al
On 12/31/05, Tom Kern [EMAIL PROTECTED] wrote:

Thats it.

Isn't that the way its refered to in MS-speak?

I hope i didn't just make that up...

On 12/30/05, Brian Desmond [EMAIL PROTECTED]
 wrote: 
presumably setting the scriptPath attribute on accounts...Thanks,Brian Desmond
[EMAIL PROTECTED]c - 312.731.3132From: 
[EMAIL PROTECTED] on behalf of Al MulnickSent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] icmp'sWhen you say legacy way, what does that mean exactly?On 12/30/05, Tom Kern 
[EMAIL PROTECTED] wrote: would this also affect clients from getting logon scripts? and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's.  Thanks again
 On 12/30/05, Brian Desmond [EMAIL PROTECTED]  wrote: You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients. 
 The rules look something like this: access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echo access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply 
 Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network. 
 Thanks, Brian Desmond [EMAIL PROTECTED]
 c - 312.731.3132   From: 
[EMAIL PROTECTED] on behalf of Tom Kern Sent: Fri 12/30/2005 9:25 AM To: activedirectory  Subject: [ActiveDir] icmp's What affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest?
 any? I know clients ping dc's to see which responds first and later ping dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients? 
 I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was wondering if thats something i should worry about in a win2k network. 
 Thanks


Re: [ActiveDir] icmp's

2006-01-01 Thread Tom Kern
I thought i read somewhere in some MS doc it being refered to as legacy since now you can put multiple logon scripts in GPO's and that they recommend doing it that way.

everytime a new OS or feature comes out, MS tends to refer to the previous os/feature as legacy or down-level.
maybe i just made a silly assumption that using a logon script as a user attritbute( i guess somewhat simillar to the way NT did it)instead of a GPO was legacy.
thanks

On 1/1/06, Al Mulnick [EMAIL PROTECTED] wrote:

I personally haven't heard it referred to as legacy. I think that may be because it wasn't a legacy method when I last heard it ;)

I haven't tested this, so your mileage may vary but: the legacy method would have been created and designed for a time before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was disabled. Several things will break, but I don't believe that's one of them. 


Test it. You'll know for sure then right? Besides, I don't imagine alot of networks out there are configured with ICMPdisabled like that.

Al

On 12/31/05, Tom Kern [EMAIL PROTECTED] wrote:
 

Thats it.

Isn't that the way its refered to in MS-speak?

I hope i didn't just make that up...

On 12/30/05, Brian Desmond [EMAIL PROTECTED] 
 wrote: 
presumably setting the scriptPath attribute on accounts...Thanks,Brian Desmond
[EMAIL PROTECTED]c - 312.731.3132From: 
[EMAIL PROTECTED] on behalf of Al MulnickSent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.org 
Subject: Re: [ActiveDir] icmp'sWhen you say legacy way, what does that mean exactly?On 12/30/05, Tom Kern 
 [EMAIL PROTECTED] wrote: would this also affect clients from getting logon scripts? and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's.  Thanks again 
 On 12/30/05, Brian Desmond [EMAIL PROTECTED]  wrote: You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients. 
 The rules look something like this: access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echo access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply 
 Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network. 
 Thanks, Brian Desmond [EMAIL PROTECTED]
 c - 312.731.3132   From: 
[EMAIL PROTECTED] on behalf of Tom Kern Sent: Fri 12/30/2005 9:25 AM To: activedirectory  Subject: [ActiveDir] icmp's What affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest? 
 any? I know clients ping dc's to see which responds first and later ping dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients? 
 I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was wondering if thats something i should worry about in a win2k network. 
 Thanks


RE: Re: [ActiveDir] icmp's

2006-01-01 Thread Mark Parris








This is from the Microsoft article  Enterprise logon scripts



By default, logon
scripts written as either .bat or .cmd files (so-called legacy
logon scripts)
run in a visible command window; when executed, a command window open up on the
screen. To prevent a user from closing the command window (and thus terminating
the script), you can the Run legacy logon scripts
hidden enable policy. This ensures that all legacy logon scripts run
in a hidden window.



Mark











From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: 01 January 2006 14:18
To: ActiveDir@mail.activedir.org
Subject: [Norton AntiSpam] Re:
[ActiveDir] icmp's







I thought i read somewhere in some MS doc it being refered to as
legacy since now you can put multiple logon scripts in GPO's and
that they recommend doing it that way.











everytime a new OS or feature comes out, MS tends to refer to the
previous os/feature as legacy or down-level.





maybe i just made a silly assumption that using a logon script as a
user attritbute( i guess somewhat simillar to the way NT did it)instead
of a GPO was legacy.





thanks













On 1/1/06, Al
Mulnick [EMAIL PROTECTED]
wrote: 



I personally haven't heard it referred to as legacy.
I think that may be because it wasn't a legacy method when I last heard it ;)











I haven't tested this, so your mileage may vary but: the
legacy method would have been created and designed for a time
before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was
disabled. Several things will break, but I don't believe that's one of
them. 











Test it. You'll know for sure then right? Besides, I don't
imagine alot of networks out there are configured with ICMPdisabled
like that.











Al









On 12/31/05, Tom
Kern [EMAIL PROTECTED]
wrote: 



Thats it.











Isn't that the way its refered to in MS-speak?











I hope i didn't just make that up...









On 12/30/05, Brian
Desmond [EMAIL PROTECTED]
 wrote: 

presumably setting the
scriptPath attribute on accounts...

Thanks,
Brian Desmond
[EMAIL PROTECTED]

c - 312.731.3132



From: [EMAIL PROTECTED]
on behalf of Al Mulnick
Sent: Fri 12/30/2005 8:13 PM
To: ActiveDir@mail.activedir.org

Subject: Re: [ActiveDir] icmp's


When you say legacy way, what does that mean exactly?


On 12/30/05, Tom Kern 
[EMAIL PROTECTED] wrote:

 would this also affect clients from
getting logon scripts?
 and when i say logon scripts, i mean the
legacy way of distributing them, NOT thru GPO's. 

 Thanks again 



 On 12/30/05, Brian Desmond [EMAIL PROTECTED]
 wrote:


You need to enable ICMP echo source clients dest dc's, and icmp echo-reply
source dc's dest clients. 


The rules look something like this:


access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers
echo


access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any
echo-reply 


Have your network people considered rate-limiting ICMP packets rather than
shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute,
time-exceeded) are necessary pieces of a network. 


Thanks,

Brian Desmond

[EMAIL PROTECTED]


c - 312.731.3132


 


From: [EMAIL PROTECTED]
on behalf of Tom Kern

Sent: Fri 12/30/2005 9:25 AM

To: activedirectory 

Subject: [ActiveDir] icmp's



What affect would blocking icmp packets on all vlans have on win2k/xp client
logons in a win2k forest? 

any?


I know clients ping dc's to see which responds first and later ping dc's to
determine round trip time for GPO processing, but would blocking icmp's have
any adverse affects on clients? 

I only ask because my corp blocks icmp's on all our vlans and i get a lot of
event id 1000 from Usernev with error code of 59 which when i looked up, refers
to network connectivity issues. i think this event id is related to the fact we
block icmp packets and i was wondering if thats something i should worry about
in a win2k network. 

Thanks


































RE: Re: [ActiveDir] icmp's

2006-01-01 Thread joe




Come on, who ya going to believe? Microsoft who has all 
sorts of typoes in the documentation (I just saw 
a reference to objectcategory=user in an MS doc 2 days ago, I still have the 
bruise on my forehead)or our trusted source... 
Al?

:o)

Personally I like theold style logon scripts better than GPO logon scripts. Way too many things impact GPO 
functions. I never found it difficult to 
write logon scripts designed to work on specific users nor machines sodidn't need the sorting capability of 
GPOs. Overall I am ok levelhappy 
with having a default domain GPO and default dc GPO as the only GPOs. I would 
rather not set domain policy with GPOs. 
While I am at it, I think we are far beyond the point that we should have the 
ability to programmatically handle settings in policies. 





From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Mark 
ParrisSent: Sunday, January 01, 2006 9:58 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's


This is from the Microsoft article  Enterprise logon 
scripts

By default, logon scripts written as 
either .bat or .cmd files (so-called "legacy" logon 
scripts) run in a visible command window; when executed, a command 
window open up on the screen. To prevent a user from closing the command window 
(and thus terminating the script), you can the Run legacy logon scripts 
hidden enable policy. This ensures that all legacy logon scripts run 
in a hidden window.

Mark





From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On Behalf Of Tom KernSent: 01 January 2006 14:18To: ActiveDir@mail.activedir.orgSubject: [Norton AntiSpam] Re: [ActiveDir] 
icmp's


I thought i read somewhere in some MS doc it being 
refered to as "legacy" since now you can put multiple logon scripts in GPO's and 
that they recommend doing it that way.



everytime a new OS or feature comes out, MS tends to 
refer to the previous os/feature as legacy or 
down-level.

maybe i just made a silly assumption that using a logon 
script as a user attritbute( i guess somewhat simillar to the way NT did 
it)instead of a GPO was "legacy".

thanks



On 1/1/06, Al Mulnick [EMAIL PROTECTED] 
wrote: 

I personally haven't heard it referred to as 
"legacy". I think that may be because it wasn't a legacy method when I 
last heard it ;)



I haven't tested this, so your mileage may vary but: the 
"legacy" method would have been created and designed for a time before ICMP was 
the norm. As such, I wouldn't expect that to break if ICMP was disabled. 
Several things will break, but I don't believe that's one of them. 




Test it. You'll know for sure then right? 
Besides, I don't imagine alot of networks out there are configured with 
ICMPdisabled like that.



Al


On 12/31/05, Tom Kern [EMAIL PROTECTED] wrote: 


Thats it.



Isn't that the way its refered to in 
MS-speak?



I hope i didn't just make that 
up...


On 12/30/05, Brian Desmond [EMAIL PROTECTED] 
 wrote: 
presumably setting the scriptPath attribute 
on accounts...Thanks,Brian Desmond[EMAIL PROTECTED]c - 
312.731.3132From: [EMAIL PROTECTED] on behalf of Al 
MulnickSent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] 
icmp'sWhen you say legacy way, what does that mean 
exactly?On 12/30/05, Tom Kern  [EMAIL PROTECTED] 
wrote: would this also affect 
clients from getting logon scripts? and 
when i say logon scripts, i mean the legacy way of distributing them, NOT thru 
GPO's.  Thanks again 
 On 12/30/05, Brian Desmond 
[EMAIL PROTECTED]  
wrote: 
You need to enable ICMP echo source clients dest dc's, and icmp echo-reply 
source dc's dest clients. 
 
The rules look something like 
this: 
access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers 
echo 
access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any 
echo-reply 
 
Have your network people considered rate-limiting ICMP packets rather than 
shutting them down all together. IMHO that's the correct way to handle this. 
Ping (echo, echo-reply) and traceroute 
(traceroute, time-exceeded) are necessary pieces of a network. 
 
Thanks, 
Brian 
Desmond 
[EMAIL PROTECTED] 
c - 
312.731.3132 
 
 
From: [EMAIL PROTECTED] on behalf of Tom 
Kern 
Sent: Fri 12/30/2005 9:25 
AM 
To: activedirectory 
 
Subject: [ActiveDir] 
icmp's 
What affect would blocking icmp packets on all vlans have on win2k/xp client 
logons in a win2k forest? 
 
any? 
I know clients ping dc's to see which responds first and later ping dc's to 
determine round trip time for GPO processing, but would blocking icmp's have any 
adverse affects on clients? 
 
I only ask because my corp blocks icmp's on all our vlans and i get a lot of 
event id 1000 from Usernev with error code of 59 which when i looked up, refers 
to network connectivity issues. i think this event id is related to the fact we 
block icmp packets and i was

RE: [ActiveDir] icmp's

2006-01-01 Thread joe



I would agree, the old style logon scripts should be fine, 
UNLESS you have implemented your own speed sensing based on icmpin the 
logon script (many of us did that long before MS did it for those who didn't 
figure it out). 

Note Exchange doesn't take kindly to ICMP echo being 
disabled either. If Exchange can't ping a DC, DSACCESS does not see that DC 
unless you have specially configured it. If you never want to fail outside of a 
segment then that is the way to do it, but most people would rather fail over to 
any DC versus say, nah, those are two far away even though none of my local DCs 
are available if things go pear shaped. 




From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Al 
MulnickSent: Sunday, January 01, 2006 9:07 AMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] 
icmp's

I personally haven't heard it referred to as "legacy". I think that 
may be because it wasn't a legacy method when I last heard it ;)

I haven't tested this, so your mileage may vary but: the "legacy" method 
would have been created and designed for a time before ICMP was the norm. As 
such, I wouldn't expect that to break if ICMP was disabled. Several things 
will break, but I don't believe that's one of them. 

Test it. You'll know for sure then right? Besides, I don't 
imagine alot of networks out there are configured with ICMPdisabled 
like that.

Al
On 12/31/05, Tom Kern 
[EMAIL PROTECTED] wrote: 

  Thats it.
  
  Isn't that the way its refered to in MS-speak?
  
  I hope i didn't just make that up...
  
  On 12/30/05, Brian 
  Desmond [EMAIL PROTECTED] 
   wrote: 
  presumably 
setting the scriptPath attribute on accounts...Thanks,Brian 
Desmond[EMAIL PROTECTED]c - 
312.731.3132From: [EMAIL PROTECTED] on behalf of Al 
MulnickSent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] 
icmp'sWhen you say legacy way, what does that mean 
exactly?On 12/30/05, Tom Kern  [EMAIL PROTECTED] 
wrote: would this also affect 
clients from getting logon scripts? 
and when i say logon scripts, i mean the legacy way of distributing them, 
NOT thru GPO's.  Thanks again 
 On 12/30/05, Brian 
Desmond [EMAIL PROTECTED]  
wrote: 
You need to enable ICMP echo source clients dest dc's, and icmp echo-reply 
source dc's dest clients. 
 
The rules look something like 
this: 
access-list DC_VLAN_OUT line 1 permit icmp any object-group 
domain_controllers 
echo 
access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers 
any echo-reply 
 
Have your network people considered rate-limiting ICMP packets rather than 
shutting them down all together. IMHO that's the correct way to handle this. 
Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are 
necessary pieces of a network. 
 
Thanks, 
Brian 
Desmond 
[EMAIL PROTECTED] 
c - 
312.731.3132 
 
 
From: [EMAIL PROTECTED] on behalf of Tom 
Kern 
Sent: Fri 12/30/2005 9:25 
AM 
To: activedirectory 
 
Subject: [ActiveDir] 
icmp's 
What affect would blocking icmp packets on all vlans have on win2k/xp client 
logons in a win2k forest? 
 
any? 
I know clients ping dc's to see which responds first and later ping dc's to 
determine round trip time for GPO processing, but would blocking icmp's have 
any adverse affects on clients? 
 
I only ask because my corp blocks icmp's on all our vlans and i get a lot of 
event id 1000 from Usernev with error code of 59 which when i looked up, 
refers to network connectivity issues. i think this event id is related to 
the fact we block icmp packets and i was wondering if thats something i 
should worry about in a win2k network. 
 
Thanks


RE: [ActiveDir] icmp's

2006-01-01 Thread Rick Kingslan








The real benefit to the GPO method is that
you can target scripts to the same _groups_
in which the GPO would affect  and you can target Computer groups, which
you cant do (for obvious reasons) with logon scripts. This lends itself
to some very elegant solutions that Im sure one could do with some fancy
environment or user/computer-based variables or attribute checking. Of course,
it begs to obvious question  Why?



If it means developing a whole manner and
method to get variables and/or attributes identified and called, when you only
would need to use GPO-based scripts, I think the answer becomes self-evident.



As to being called Legacy,
which seems to be the real problem here, its simply verbiage that I dont
think Id get my panties in a bunch over. The user-focused versus the
GPO focused scripts are going to be around as far out as I can see (and, thats
really not THAT far, to be honest).



Cheers!



Rick











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern
Sent: Sunday, January 01, 2006
8:18 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] icmp's







I thought i read somewhere in some MS doc it being refered to as
legacy since now you can put multiple logon scripts in GPO's and
that they recommend doing it that way.











everytime a new OS or feature comes out, MS tends to refer to the
previous os/feature as legacy or down-level.





maybe i just made a silly assumption that using a logon script as a
user attritbute( i guess somewhat simillar to the way NT did it)instead
of a GPO was legacy.





thanks













On 1/1/06, Al
Mulnick [EMAIL PROTECTED]
wrote: 



I personally haven't heard it referred to as legacy.
I think that may be because it wasn't a legacy method when I last heard it ;)











I haven't tested this, so your mileage may vary but: the
legacy method would have been created and designed for a time
before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was
disabled. Several things will break, but I don't believe that's one of
them. 











Test it. You'll know for sure then right? Besides, I don't
imagine alot of networks out there are configured with ICMPdisabled
like that.











Al









On 12/31/05, Tom
Kern [EMAIL PROTECTED]
wrote: 



Thats it.











Isn't that the way its refered to in MS-speak?











I hope i didn't just make that up...









On 12/30/05, Brian
Desmond [EMAIL PROTECTED]
 wrote: 

presumably setting the
scriptPath attribute on accounts...

Thanks,
Brian Desmond
[EMAIL PROTECTED]

c - 312.731.3132



From: [EMAIL PROTECTED]
on behalf of Al Mulnick
Sent: Fri 12/30/2005 8:13 PM
To: ActiveDir@mail.activedir.org

Subject: Re: [ActiveDir] icmp's


When you say legacy way, what does that mean exactly?


On 12/30/05, Tom Kern 
[EMAIL PROTECTED] wrote:

 would this also affect clients from
getting logon scripts?
 and when i say logon scripts, i mean the
legacy way of distributing them, NOT thru GPO's. 

 Thanks again 



 On 12/30/05, Brian Desmond [EMAIL PROTECTED]
 wrote:


You need to enable ICMP echo source clients dest dc's, and icmp echo-reply
source dc's dest clients. 


The rules look something like this:


access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers
echo


access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any
echo-reply 


Have your network people considered rate-limiting ICMP packets rather than
shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute,
time-exceeded) are necessary pieces of a network. 


Thanks,

Brian Desmond

[EMAIL PROTECTED]


c - 312.731.3132


 


From: [EMAIL PROTECTED]
on behalf of Tom Kern

Sent: Fri 12/30/2005 9:25 AM

To: activedirectory 

Subject: [ActiveDir] icmp's



What affect would blocking icmp packets on all vlans have on win2k/xp client
logons in a win2k forest? 

any?


I know clients ping dc's to see which responds first and later ping dc's to
determine round trip time for GPO processing, but would blocking icmp's have
any adverse affects on clients? 

I only ask because my corp blocks icmp's on all our vlans and i get a lot of event
id 1000 from Usernev with error code of 59 which when i looked up, refers to
network connectivity issues. i think this event id is related to the fact we
block icmp packets and i was wondering if thats something i should worry about
in a win2k network. 

Thanks


































RE: Re: [ActiveDir] icmp's

2006-01-01 Thread Rick Kingslan








joe stood up and attempted to smack Mark
Parris with a large trout, saying:



I would rather not set domain
policy with GPOs. While I am at it, I think we are far beyond the point that we
should have the ability to programmatically handle settings in policies.



Huh? Can you explain both
statements, joe? I understand the context of the first, but not
why. The second  I just am not sure what youre getting
at. Help out an old haggard road warrior.



;o)



Rick











From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January 01, 2006
10:50 AM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir]
icmp's





Come on, who ya going to believe?
Microsoft who has all sorts of typoes in the documentation (I just saw a
reference to objectcategory=user in an MS doc 2 days ago, I still have the
bruise on my forehead)or our trusted source... Al?



:o)



Personally I like theold style logon
scripts better than GPO logon scripts. Way too many things impact GPO
functions. I never found it difficult to write logon scripts designed to work
on specific users nor machines sodidn't need the sorting capability of
GPOs. Overall I am ok levelhappy with having a default domain GPO and
default dc GPO as the only GPOs. I would rather not set domain policy with
GPOs. While I am at it, I think we are far beyond the point that we should have
the ability to programmatically handle settings in policies. 













From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Parris
Sent: Sunday, January 01, 2006
9:58 AM
To: ActiveDir@mail.activedir.org
Subject: RE: Re: [ActiveDir] icmp's

This is from the Microsoft article  Enterprise logon scripts



By default, logon
scripts written as either .bat or .cmd files (so-called legacy
logon scripts)
run in a visible command window; when executed, a command window open up on the
screen. To prevent a user from closing the command window (and thus terminating
the script), you can the Run legacy logon scripts
hidden enable policy. This ensures that all legacy logon scripts run
in a hidden window.



Mark











From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: 01 January 2006 14:18
To: ActiveDir@mail.activedir.org
Subject: [Norton AntiSpam] Re:
[ActiveDir] icmp's







I thought i read somewhere in some MS doc it being refered to as
legacy since now you can put multiple logon scripts in GPO's and
that they recommend doing it that way.











everytime a new OS or feature comes out, MS tends to refer to the
previous os/feature as legacy or down-level.





maybe i just made a silly assumption that using a logon script as a
user attritbute( i guess somewhat simillar to the way NT did it)instead
of a GPO was legacy.





thanks













On 1/1/06, Al
Mulnick [EMAIL PROTECTED]
wrote: 



I personally haven't heard it referred to as legacy.
I think that may be because it wasn't a legacy method when I last heard it ;)











I haven't tested this, so your mileage may vary but: the
legacy method would have been created and designed for a time
before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was
disabled. Several things will break, but I don't believe that's one of
them. 











Test it. You'll know for sure then right? Besides, I don't
imagine alot of networks out there are configured with ICMPdisabled
like that.











Al









On 12/31/05, Tom
Kern [EMAIL PROTECTED]
wrote: 



Thats it.











Isn't that the way its refered to in MS-speak?











I hope i didn't just make that up...









On 12/30/05, Brian
Desmond [EMAIL PROTECTED]
 wrote: 

presumably setting the
scriptPath attribute on accounts...

Thanks,
Brian Desmond
[EMAIL PROTECTED]

c - 312.731.3132



From: [EMAIL PROTECTED]
on behalf of Al Mulnick
Sent: Fri 12/30/2005 8:13 PM
To: ActiveDir@mail.activedir.org

Subject: Re: [ActiveDir] icmp's


When you say legacy way, what does that mean exactly?


On 12/30/05, Tom Kern 
[EMAIL PROTECTED] wrote:

 would this also affect clients from
getting logon scripts?
 and when i say logon scripts, i mean the
legacy way of distributing them, NOT thru GPO's. 

 Thanks again 



 On 12/30/05, Brian Desmond [EMAIL PROTECTED]
 wrote:


You need to enable ICMP echo source clients dest dc's, and icmp echo-reply
source dc's dest clients. 


The rules look something like this:


access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers
echo


access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any
echo-reply 


Have your network people considered rate-limiting ICMP packets rather than
shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute,
time-exceeded) are necessary pieces of a network. 


Thanks,

Brian Desmond

[EMAIL PROTECTED]


c - 312.731.3132


 


From: [EMAIL

RE: [ActiveDir] icmp's

2006-01-01 Thread Rick Kingslan








Note Exchange doesn't take kindly
to ICMP echo being disabled either. If Exchange can't ping a DC, DSACCESS does
not see that DC unless you have specially configured it.



Which, I always thought was a pretty funny
way of doing things anyway. As you are well aware, Ping
doesnt mean alive and healthy. I know of many people who have
spent hours to days troubleshooting a problem just to find that the machine
that they first suspected as being the problem pinged just fine. Sadly,
it was dead from the neck up and port 389 and 3268 were non-responsive (along
with all of the other really important stuff).



Rick









From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January 01, 2006
10:54 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's





I would agree, the old style logon scripts
should be fine, UNLESS you have implemented your own speed sensing based on
icmpin the logon script (many of us did that long before MS did it for
those who didn't figure it out). 



Note Exchange doesn't take kindly to ICMP
echo being disabled either. If Exchange can't ping a DC, DSACCESS does not see
that DC unless you have specially configured it. If you never want to fail
outside of a segment then that is the way to do it, but most people would
rather fail over to any DC versus say, nah, those are two far away even though
none of my local DCs are available if things go pear shaped. 













From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Sunday, January 01, 2006
9:07 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] icmp's



I personally haven't heard it referred to as legacy.
I think that may be because it wasn't a legacy method when I last heard it ;)











I haven't tested this, so your mileage may vary but: the
legacy method would have been created and designed for a time
before ICMP was the norm. As such, I wouldn't expect that to break if ICMP was
disabled. Several things will break, but I don't believe that's one of
them. 











Test it. You'll know for sure then right? Besides, I don't
imagine alot of networks out there are configured with ICMPdisabled
like that.











Al







On 12/31/05, Tom
Kern [EMAIL PROTECTED]
wrote: 



Thats it.











Isn't that the way its refered to in MS-speak?











I hope i didn't just make that up...









On 12/30/05, Brian
Desmond [EMAIL PROTECTED]
 wrote: 

presumably setting the
scriptPath attribute on accounts...

Thanks,
Brian Desmond
[EMAIL PROTECTED]

c - 312.731.3132



From: [EMAIL PROTECTED]
on behalf of Al Mulnick
Sent: Fri 12/30/2005 8:13 PM
To: ActiveDir@mail.activedir.org

Subject: Re: [ActiveDir] icmp's


When you say legacy way, what does that mean exactly?


On 12/30/05, Tom Kern 
[EMAIL PROTECTED] wrote:

 would this also affect clients from
getting logon scripts?
 and when i say logon scripts, i mean the
legacy way of distributing them, NOT thru GPO's. 

 Thanks again 



 On 12/30/05, Brian Desmond [EMAIL PROTECTED]
 wrote:


You need to enable ICMP echo source clients dest dc's, and icmp echo-reply
source dc's dest clients. 


The rules look something like this:


access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers
echo


access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any
echo-reply 


Have your network people considered rate-limiting ICMP packets rather than
shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute,
time-exceeded) are necessary pieces of a network. 


Thanks,

Brian Desmond

[EMAIL PROTECTED]


c - 312.731.3132


 


From: [EMAIL PROTECTED]
on behalf of Tom Kern

Sent: Fri 12/30/2005 9:25 AM

To: activedirectory 

Subject: [ActiveDir] icmp's



What affect would blocking icmp packets on all vlans have on win2k/xp client
logons in a win2k forest? 

any?


I know clients ping dc's to see which responds first and later ping dc's to
determine round trip time for GPO processing, but would blocking icmp's have
any adverse affects on clients? 

I only ask because my corp blocks icmp's on all our vlans and i get a lot of
event id 1000 from Usernev with error code of 59 which when i looked up, refers
to network connectivity issues. i think this event id is related to the fact we
block icmp packets and i was wondering if thats something i should worry about
in a win2k network. 

Thanks




























RE: Re: [ActiveDir] icmp's

2006-01-01 Thread joe



Rick came out of the woodwork and 
rambled:

"Huh? Can you 
explain both statements, joe?"

First statement being, I would rather not set domain 
policies in GPOs... I am referring to actual domain policy, not a policy applied 
to all machines in the domain. You know, the original meaning of domain policy. 
Pushing any policy to domain controllers that has to do with configuration of AD 
is assinine in my opinion, you already have a mechanism to push those changes 
through the environment. You don't need to use another one. Also it is a point 
of confusion for tons and tons of people. There should be a clear divisor 
between true domain policy and a policy that gets applied to each individual 
machine. 

Second statement being programmatically handling settings 
in policies... You can't set GPO settings programmatically unless you reverse 
the format of the policy information in sysvol. All you can do is 
backup/restore/export/import/enable/disable. What if I want to take all policies 
under the OU Buildings (which could be tens, hundreds, or thousands of policy 
files) and set one setting, for the sake of argument say password policy for 
local machinesis equal to some set of values based on the specific OU name 
that the policy is applied to (say it has finance in the name of the OU) how 
will you do that programmatically without directly hacking the policy files 
which last I heard wasn't supported?






From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Rick 
KingslanSent: Sunday, January 01, 2006 1:09 PMTo: [EMAIL PROTECTED]Subject: RE: Re: [ActiveDir] 
icmp's


joe stood up and 
attempted to smack Mark Parris with a large trout, 
saying:

I would rather not set 
domain policy with GPOs. While I am at it, I think we are far beyond the point 
that we should have the ability to programmatically handle settings in 
policies.

Huh? Can you 
explain both statements, joe? I understand the context of the first, but 
not why. The second  I just am not sure what youre getting at. 
Help out an old haggard road warrior.

;o)

Rick





From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Sunday, January 01, 2006 10:50 
AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's

Come on, who ya going 
to believe? Microsoft who has all sorts of typoes in the documentation (I just 
saw a reference to objectcategory=user in an MS doc 2 days ago, I still have the 
bruise on my forehead)or our trusted source... 
Al?

:o)

Personally I like 
theold style logon scripts better than GPO logon scripts. Way too many 
things impact GPO functions. I never found it difficult to write logon scripts 
designed to work on specific users nor machines sodidn't need the sorting 
capability of GPOs. Overall I am ok levelhappy with having a default 
domain GPO and default dc GPO as the only GPOs. I would rather not set domain 
policy with GPOs. While I am at it, I think we are far beyond the point that we 
should have the ability to programmatically handle settings in policies. 







From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Mark 
ParrisSent: Sunday, January 
01, 2006 9:58 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's
This is from the Microsoft article  Enterprise logon 
scripts

By default, logon scripts written as 
either .bat or .cmd files (so-called "legacy" logon 
scripts) run in a visible command window; when executed, a command 
window open up on the screen. To prevent a user from closing the command window 
(and thus terminating the script), you can the Run legacy logon scripts 
hidden enable policy. This ensures that all legacy logon scripts run 
in a hidden window.

Mark





From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED]] On Behalf Of Tom KernSent: 01 January 2006 14:18To: ActiveDir@mail.activedir.orgSubject: [Norton AntiSpam] Re: [ActiveDir] 
icmp's


I thought i read somewhere in some MS doc it being 
refered to as "legacy" since now you can put multiple logon scripts in GPO's and 
that they recommend doing it that way.



everytime a new OS or feature comes out, MS tends to 
refer to the previous os/feature as legacy or 
down-level.

maybe i just made a silly assumption that using a logon 
script as a user attritbute( i guess somewhat simillar to the way NT did 
it)instead of a GPO was "legacy".

thanks



On 1/1/06, Al Mulnick [EMAIL PROTECTED] 
wrote: 

I personally haven't heard it referred to as 
"legacy". I think that may be because it wasn't a legacy method when I 
last heard it ;)



I haven't tested this, so your mileage may vary but: the 
"legacy" method would have been created and designed for a time before ICMP was 
the norm. As such, I wouldn't expect that to break if ICMP was disabled. 
Several things will break, but I don't believe that's one of them. 




Test it. You'll know for sure then right? 
Besides, I don't imagine alot of networks 

RE: [ActiveDir] icmp's

2006-01-01 Thread joe



I don't often find myself in the position of defending the 
Exchange folks but this isn't just an Exchange thing, the ICMP echo has been a 
"are you alive" test for a very long time. I understand why they do it, I have 
written several scripts and tools that do something similar. It can be 
considerablyfaster. When you are testing suitability or capability of a 
bunch of systems, sending anICMPping to see if the machine is live 
is considerably faster in many circumstancesthan sending higher level 
calls, both for machines that are live or dead. This is especially true if using 
netbios calls, in that case querying can cause a system to hang where a 
simpleICMP ping tells you right away if you should even bother. 


Blocking all ICMP in an internal network is generally silly 
in my opinion unless something is abusing it at the time. It is often a 
thoughtless reactive, "well we will certainly stop those viruses" knee jerk. Its 
like stripping all zip files in an email system because a virus is operating 
through zips. We don't a better way and we don't have the ability and/or time to 
think up a better way so lets get out the sledgehammer...

Once you use ICMP you can go on to use higher level forms 
of testing. It is also a great way for diagnostician's to try and work out 
network issues... is ICMP ECHO getting through? No, well then we don't have to 
look at complicated upper level issues, we can focus on core basic network 
connectivity.

One thing the Exchange folks did that I am not in agreement 
with is if a DC is a config DC and is operating poorly Exchange will really 
avoid switching for config functionality if the ping is still there. That isn't 
a stateless connection so I can understand the reluctance but it can be a 
serious pain at times.



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Rick 
KingslanSent: Sunday, January 01, 2006 1:18 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's


Note Exchange doesn't 
take kindly to ICMP echo being disabled either. If Exchausnge can't ping a DC, DSACCESS does 
not see that DC unless you have specially configured it.

Which, I always thought 
was a pretty funny way of doing things anyway. As you are well aware, 
Ping doesnt mean alive and healthy. I 
know of many people who have spent hours to days troubleshooting a problem just 
to find that the machine that they first suspected as being the problem pinged 
just fine. Sadly, it was dead from the neck up and port 389 and 3268 were 
non-responsive (along with all of the other really important 
stuff).

Rick




From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Sunday, January 01, 2006 10:54 
AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's

I would agree, the old 
style logon scripts should be fine, UNLESS you have implemented your own speed 
sensing based on icmpin the logon script (many of us did that long before 
MS did it for those who didn't figure it out). 

Note Exchange doesn't 
take kindly to ICMP echo being disabled either. If Exchange can't ping a DC, 
DSACCESS does not see that DC unless you have specially configured it. If you 
never want to fail outside of a segment then that is the way to do it, but most 
people would rather fail over to any DC versus say, nah, those are two far away 
even though none of my local DCs are available if things go pear shaped. 







From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Al 
MulnickSent: Sunday, January 
01, 2006 9:07 AMTo: 
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] 
icmp's

I personally haven't heard it referred to as 
"legacy". I think that may be because it wasn't a legacy method when I 
last heard it ;)



I haven't tested this, so your mileage may vary but: the 
"legacy" method would have been created and designed for a time before ICMP was 
the norm. As such, I wouldn't expect that to break if ICMP was disabled. 
Several things will break, but I don't believe that's one of them. 




Test it. You'll know for sure then right? 
Besides, I don't imagine alot of networks out there are configured with 
ICMPdisabled like that.



Al

On 12/31/05, Tom Kern [EMAIL PROTECTED] 
wrote: 

Thats it.



Isn't that the way its refered to in 
MS-speak?



I hope i didn't just make that 
up...


On 12/30/05, Brian Desmond [EMAIL PROTECTED] 
 wrote: 
presumably setting the scriptPath attribute 
on accounts...Thanks,Brian Desmond[EMAIL PROTECTED]c - 
312.731.3132From: [EMAIL PROTECTED] on behalf of Al 
MulnickSent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] 
icmp'sWhen you say legacy way, what does that mean 
exactly?On 12/30/05, Tom Kern  [EMAIL PROTECTED] 
wrote: would this also affect 
clients from getting logon scripts? and 
when i say logon scripts, i mean the legacy way of distributing them, NOT thru 
GPO's.  Thanks again 
 On 12/30/05, 

RE: [ActiveDir] icmp's

2006-01-01 Thread Brian Desmond
The whole block ICMP thing is I think in many ways dating to the blaster and 
nachi outbreaks when routers were getting driven to 100% CPU as hundreds of 
machines were slamming ICMP and RPC traffic across them. Newer gear has the 
ability to rate limit ICMP traffic. All your admins need to do is rate limit 
ICMP to something like 512kb/sec and drop on exceed. Problem solved. In the 
event yuou have an outbreak because you don't do patch management, go in the 
router and set the drop limit to something like 64kb/sec or worst case put the 
ACL to shutdown ICMP all together. Either way your better off than no ICMP 
24/7
 
Thanks,
Brian Desmond
[EMAIL PROTECTED]
 
c - 312.731.3132



From: [EMAIL PROTECTED] on behalf of joe
Sent: Sun 1/1/2006 3:17 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's


I don't often find myself in the position of defending the Exchange folks but 
this isn't just an Exchange thing, the ICMP echo has been a are you alive 
test for a very long time. I understand why they do it, I have written several 
scripts and tools that do something similar. It can be considerably faster. 
When you are testing suitability or capability of a bunch of systems, sending 
an ICMP ping to see if the machine is live is considerably faster in many 
circumstances than sending higher level calls, both for machines that are live 
or dead. This is especially true if using netbios calls, in that case querying 
can cause a system to hang where a simple ICMP ping tells you right away if you 
should even bother. 
 
Blocking all ICMP in an internal network is generally silly in my opinion 
unless something is abusing it at the time. It is often a thoughtless reactive, 
well we will certainly stop those viruses knee jerk. Its like stripping all 
zip files in an email system because a virus is operating through zips. We 
don't a better way and we don't have the ability and/or time to think up a 
better way so lets get out the sledgehammer...
 
Once you use ICMP you can go on to use higher level forms of testing. It is 
also a great way for diagnostician's to try and work out network issues... is 
ICMP ECHO getting through? No, well then we don't have to look at complicated 
upper level issues, we can focus on core basic network connectivity.
 
One thing the Exchange folks did that I am not in agreement with is if a DC is 
a config DC and is operating poorly Exchange will really avoid switching for 
config functionality if the ping is still there. That isn't a stateless 
connection so I can understand the reluctance but it can be a serious pain at 
times.
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Sunday, January 01, 2006 1:18 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's



Note Exchange doesn't take kindly to ICMP echo being disabled either. If Excha 
us nge can't ping a DC, DSACCESS does not see that DC unless you have specially 
configured it.

 

Which, I always thought was a pretty funny way of doing things anyway.  As you 
are well aware, Ping doesn't mean alive and healthy.  I know of many people who 
have spent hours to days troubleshooting a problem just to find that the 
machine that they first suspected as being the problem pinged just fine.  
Sadly, it was dead from the neck up and port 389 and 3268 were non-responsive 
(along with all of the other really important stuff).

 

Rick



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January 01, 2006 10:54 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's

 

I would agree, the old style logon scripts should be fine, UNLESS you have 
implemented your own speed sensing based on icmp in the logon script (many of 
us did that long before MS did it for those who didn't figure it out). 

 

Note Exchange doesn't take kindly to ICMP echo being disabled either. If 
Exchange can't ping a DC, DSACCESS does not see that DC unless you have 
specially configured it. If you never want to fail outside of a segment then 
that is the way to do it, but most people would rather fail over to any DC 
versus say, nah, those are two far away even though none of my local DCs are 
available if things go pear shaped. 

 

 

 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Sunday, January 01, 2006 9:07 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] icmp's

I personally haven't heard it referred to as legacy.  I think that may be 
because it wasn't a legacy method when I last heard it ;)

 

I haven't tested this, so your mileage may vary but: the legacy method would 
have been created and designed for a time before ICMP was the norm. As such, I 
wouldn't expect that to break if ICMP was disabled.  Several things will break, 
but I don't believe that's one of them

RE: [ActiveDir] icmp's

2006-01-01 Thread joe



Yep, something else I have seen in smarter networking 
environments is a honeypot system where you trap all ICMP traffic bound for 
non-routable internal networks and then a script that shuts the ports 
downon the switches of the machines sending that traffic. Someone with an 
infected machine who all of a sudden can't get network connectivity is bound to 
yell for help at which point the boys with the stuffed pillow cases show up 



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Brian 
DesmondSent: Sunday, January 01, 2006 5:11 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's


The whole block ICMP 
thing is I think in many ways dating to the blaster and nachi outbreaks when 
routers were getting driven to 100% CPU as hundreds of machines were slamming 
ICMP and RPC traffic across them. Newer gear has the ability to rate limit ICMP 
traffic. All your admins need to do is rate limit ICMP to something like 
512kb/sec and drop on exceed. Problem solved. In the event yuou have an outbreak 
because you don't do patch management, go in the router and set the drop limit 
to something like 64kb/sec or worst case put the ACL to shutdown ICMP all 
together. Either way your better off than no ICMP 24/7


Thanks,
Brian 
Desmond
[EMAIL PROTECTED]

c - 
312.731.3132


From: [EMAIL PROTECTED] on 
behalf of joeSent: Sun 1/1/2006 3:17 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's

I don't often find myself in the position of defending the 
Exchange folks but this isn't just an Exchange thing, the ICMP echo has been a 
"are you alive" test for a very long time. I understand why they do it, I have 
written several scripts and tools that do something similar. It can be 
considerablyfaster. When you are testing suitability or capability of a 
bunch of systems, sending anICMPping to see if the machine is live 
is considerably faster in many circumstancesthan sending higher level 
calls, both for machines that are live or dead. This is especially true if using 
netbios calls, in that case querying can cause a system to hang where a 
simpleICMP ping tells you right away if you should even bother. 


Blocking all ICMP in an internal network is generally silly 
in my opinion unless something is abusing it at the time. It is often a 
thoughtless reactive, "well we will certainly stop those viruses" knee jerk. Its 
like stripping all zip files in an email system because a virus is operating 
through zips. We don't a better way and we don't have the ability and/or time to 
think up a better way so lets get out the sledgehammer...

Once you use ICMP you can go on to use higher level forms 
of testing. It is also a great way for diagnostician's to try and work out 
network issues... is ICMP ECHO getting through? No, well then we don't have to 
look at complicated upper level issues, we can focus on core basic network 
connectivity.

One thing the Exchange folks did that I am not in agreement 
with is if a DC is a config DC and is operating poorly Exchange will really 
avoid switching for config functionality if the ping is still there. That isn't 
a stateless connection so I can understand the reluctance but it can be a 
serious pain at times.



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Rick 
KingslanSent: Sunday, January 01, 2006 1:18 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's


Note Exchange doesn't 
take kindly to ICMP echo being disabled either. If Exchausnge can't ping a DC, DSACCESS does 
not see that DC unless you have specially configured it.

Which, I always thought 
was a pretty funny way of doing things anyway. As you are well aware, Ping 
doesnt mean alive and healthy. I know of many people who have spent hours 
to days troubleshooting a problem just to find that the machine that they first 
suspected as being the problem pinged just fine. Sadly, it was dead from 
the neck up and port 389 and 3268 were non-responsive (along with all of the 
other really important stuff).

Rick




From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Sunday, January 01, 2006 10:54 
AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's

I would agree, the old 
style logon scripts should be fine, UNLESS you have implemented your own speed 
sensing based on icmpin the logon script (many of us did that long before 
MS did it for those who didn't figure it out). 

Note Exchange doesn't 
take kindly to ICMP echo being disabled either. If Exchange can't ping a DC, 
DSACCESS does not see that DC unless you have specially configured it. If you 
never want to fail outside of a segment then that is the way to do it, but most 
people would rather fail over to any DC versus say, nah, those are two far away 
even though none of my local DCs are available if things go pear shaped. 







From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Al 
MulnickSent: Sunday, January

RE: Re: [ActiveDir] icmp's

2006-01-01 Thread Darren Mar-Elia



Random input below


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
joeSent: Sunday, January 01, 2006 11:54 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's

Rick came out of the woodwork and 
rambled:

"Huh? Can you 
explain both statements, joe?"

First statement being, I would rather not set domain 
policies in GPOs... I am referring to actual domain policy, not a policy applied 
to all machines in the domain. You know, the original meaning of domain policy. 
Pushing any policy to domain controllers that has to do with configuration of AD 
is assinine in my opinion, you already have a mechanism to push those changes 
through the environment. You don't need to use another one. Also it is a point 
of confusion for tons and tons of people. There should be a clear divisor 
between true domain policy and a policy that gets applied to each individual 
machine. [Darren 
Mar-Elia]If you're referring to using 
stuff like Restricted Groups policy to control domain-based group membership, 
then I agree and in fact its definitely a bad idea. The thing I don't like is 
that there really isn't any decent way to remove that capability out of the box. 
I could see value in using GP to control certain AD config settings, just so 
that you could have a common interface for all Windows configuration settings, 
but GP processing should be smart enough to say, hey, I'll only apply these 
domain changes to the PDC emulator and let AD replicate them out, or something 
like that. 

Second statement being programmatically handling 
settings in policies... You can't set GPO settings programmatically unless you 
reverse the format of the policy information in sysvol. All you can do is 
backup/restore/export/import/enable/disable. What if I want to take all policies 
under the OU Buildings (which could be tens, hundreds, or thousands of policy 
files) and set one setting, for the sake of argument say password policy for 
local machinesis equal to some set of values based on the specific OU name 
that the policy is applied to (say it has finance in the name of the OU) how 
will you do that programmatically without directly hacking the policy files 
which last I heard wasn't supported?[Darren Mar-Elia]Agreed 
that an API into policy settings would be great. I've only asked about 55 times 
and it still isn't on the horizon. Why? Mostly because there is no standard 
within GP around how settings are stored. Since separate product teams 
originally wrote the various client side extensions, without any standard 
storage format, we are in the mess we have today and they'd basically have to 
re-write all of GP to make that happen, or build some interface that abstracts 
each of the various storage formats into a common API--in either case, not a 
small amount of work. That being said, it has not slowed down several ISVs from 
figuring out the storage formats and using it in their products to essentially 
give different interfaces into GP. It is do-able if you have a reasonable amount 
of programming experience. 






From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Rick 
KingslanSent: Sunday, January 01, 2006 1:09 PMTo: [EMAIL PROTECTED]Subject: RE: Re: [ActiveDir] 
icmp's


joe stood up and 
attempted to smack Mark Parris with a large trout, 
saying:

I would rather not set 
domain policy with GPOs. While I am at it, I think we are far beyond the point 
that we should have the ability to programmatically handle settings in 
policies.

Huh? Can you 
explain both statements, joe? I understand the context of the first, but 
not why. The second  I just am not sure what youre getting at. 
Help out an old haggard road warrior.

;o)

Rick





From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of joeSent: Sunday, January 01, 2006 10:50 
AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's

Come on, who ya going 
to believe? Microsoft who has all sorts of typoes in the documentation (I just 
saw a reference to objectcategory=user in an MS doc 2 days ago, I still have the 
bruise on my forehead)or our trusted source... 
Al?

:o)

Personally I like 
theold style logon scripts better than GPO logon scripts. Way too many 
things impact GPO functions. I never found it difficult to write logon scripts 
designed to work on specific users nor machines sodidn't need the sorting 
capability of GPOs. Overall I am ok levelhappy with having a default 
domain GPO and default dc GPO as the only GPOs. I would rather not set domain 
policy with GPOs. While I am at it, I think we are far beyond the point that we 
should have the ability to programmatically handle settings in policies. 







From: 
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
On Behalf Of Mark 
ParrisSent: Sunday, January 
01, 2006 9:58 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's
This is from the Microsoft article  Enterprise logon 
scripts

By default, logon scrip

RE: Re: [ActiveDir] icmp's

2006-01-01 Thread joe



Darren and I have had offline chats about this before so I 
know we are quite in sync on our thoughts. That is one of the reasons I am brave 
enough to spout them, if Darren isn't beating me up on my GPO thoughts they 
can't be too far off base. He is the GPOGUY after all. :o)

http://www.gpoguy.com/

BTW, I didn't see Darren say it, but I just found today 
that he has started blogging... http://blogs.dirteam.com/blogs/gpoguy/. 


But back to this stuff... I agree that the common interface 
is nice, but don't fully believe the info needs to be written to a policy file 
in sysvol since you have the DCs right there to write the info into AD. But 
alas, as you mention, we are talking decent reworkingof how things work 
and that includes parts of AD to do really do it cool especially in terms of 
restricted AD groups. I do believe that for some of the stuff, code is now in 
there to force the change to only occur on the PDC. I am not sure when the 
change occurred but I am guessing K3 but I was trying to chase some code a month 
or two back in the Windows source tree and it appeared there was some code in 
the GPO processing that was looking for a PDC in order to make changes. I ran 
out of time and never went back to it though. 

RE the API for settings. It is kind of sad how that 
wasn't/hasn't/maynotbe implemented. It seems like it would have been easiest way 
for MS to have done things for themselves as well. I do agree that it is 
possible to reverse it out and figure out how to do it. Of course we aren't 
supposed to but that doesn't stop progress in the MS world. 
Eventuallysomeone at MS will see what someone else is doing with their 
tech and say hey that is pretty cool, lets dothat now. 







From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Darren 
Mar-EliaSent: Sunday, January 01, 2006 7:11 PMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's

Random input below


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
joeSent: Sunday, January 01, 2006 11:54 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: Re: [ActiveDir] 
icmp's

Rick came out of the woodwork and 
rambled:

"Huh? Can you 
explain both statements, joe?"

First statement being, I would rather not set domain 
policies in GPOs... I am referring to actual domain policy, not a policy applied 
to all machines in the domain. You know, the original meaning of domain policy. 
Pushing any policy to domain controllers that has to do with configuration of AD 
is assinine in my opinion, you already have a mechanism to push those changes 
through the environment. You don't need to use another one. Also it is a point 
of confusion for tons and tons of people. There should be a clear divisor 
between true domain policy and a policy that gets applied to each individual 
machine. [Darren 
Mar-Elia]If you're referring to using 
stuff like Restricted Groups policy to control domain-based group membership, 
then I agree and in fact its definitely a bad idea. The thing I don't like is 
that there really isn't any decent way to remove that capability out of the box. 
I could see value in using GP to control certain AD config settings, just so 
that you could have a common interface for all Windows configuration settings, 
but GP processing should be smart enough to say, hey, I'll only apply these 
domain changes to the PDC emulator and let AD replicate them out, or something 
like that. 

Second statement being programmatically handling 
settings in policies... You can't set GPO settings programmatically unless you 
reverse the format of the policy information in sysvol. All you can do is 
backup/restore/export/import/enable/disable. What if I want to take all policies 
under the OU Buildings (which could be tens, hundreds, or thousands of policy 
files) and set one setting, for the sake of argument say password policy for 
local machinesis equal to some set of values based on the specific OU name 
that the policy is applied to (say it has finance in the name of the OU) how 
will you do that programmatically without directly hacking the policy files 
which last I heard wasn't supported?[Darren Mar-Elia]Agreed 
that an API into policy settings would be great. I've only asked about 55 times 
and it still isn't on the horizon. Why? Mostly because there is no standard 
within GP around how settings are stored. Since separate product teams 
originally wrote the various client side extensions, without any standard 
storage format, we are in the mess we have today and they'd basically have to 
re-write all of GP to make that happen, or build some interface that abstracts 
each of the various storage formats into a common API--in either case, not a 
small amount of work. That being said, it has not slowed down several ISVs from 
figuring out the storage formats and using it in their products to essentially 
give different interfaces into GP. It is do-able if you have a reasonable amount 
of programming 

RE: [ActiveDir] icmp's

2006-01-01 Thread Brian Desmond
Yeah, that's called a darknet or something like that. A classic one is where 
you take a random sampling of your public IP space that you're not using, and 
set up a box ou there in the perimeter to log any traffic to it. All that 
traffic is essentially bad since the IPs aren't in use. Then you have some 
dynamic manner of updating the rules in your firewall rulebase or the ACLs on 
your routers or what have you to just drop traffic from whatever source for a 
period of time.
 
Thanks,
Brian Desmond
[EMAIL PROTECTED]
 
c - 312.731.3132



From: [EMAIL PROTECTED] on behalf of joe
Sent: Sun 1/1/2006 6:23 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's


Yep, something else I have seen in smarter networking environments is a 
honeypot system where you trap all ICMP traffic bound for non-routable internal 
networks and then a script that shuts the ports down on the switches of the 
machines sending that traffic. Someone with an infected machine who all of a 
sudden can't get network connectivity is bound to yell for help at which point 
the boys with the stuffed pillow cases show up  



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond
Sent: Sunday, January 01, 2006 5:11 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's


The whole block ICMP thing is I think in many ways dating to the blaster and 
nachi outbreaks when routers were getting driven to 100% CPU as hundreds of 
machines were slamming ICMP and RPC traffic across them. Newer gear has the 
ability to rate limit ICMP traffic. All your admins need to do is rate limit 
ICMP to something like 512kb/sec and drop on exceed. Problem solved. In the 
event yuou have an outbreak because you don't do patch management, go in the 
router and set the drop limit to something like 64kb/sec or worst case put the 
ACL to shutdown ICMP all together. Either way your better off than no ICMP 
24/7
 
Thanks,
Brian Desmond
[EMAIL PROTECTED]
 
c - 312.731.3132



From: [EMAIL PROTECTED] on behalf of joe
Sent: Sun 1/1/2006 3:17 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's


I don't often find myself in the position of defending the Exchange folks but 
this isn't just an Exchange thing, the ICMP echo has been a are you alive 
test for a very long time. I understand why they do it, I have written several 
scripts and tools that do something similar. It can be considerably faster. 
When you are testing suitability or capability of a bunch of systems, sending 
an ICMP ping to see if the machine is live is considerably faster in many 
circumstances than sending higher level calls, both for machines that are live 
or dead. This is especially true if using netbios calls, in that case querying 
can cause a system to hang where a simple ICMP ping tells you right away if you 
should even bother. 
 
Blocking all ICMP in an internal network is generally silly in my opinion 
unless something is abusing it at the time. It is often a thoughtless reactive, 
well we will certainly stop those viruses knee jerk. Its like stripping all 
zip files in an email system because a virus is operating through zips. We 
don't a better way and we don't have the ability and/or time to think up a 
better way so lets get out the sledgehammer...
 
Once you use ICMP you can go on to use higher level forms of testing. It is 
also a great way for diagnostician's to try and work out network issues... is 
ICMP ECHO getting through? No, well then we don't have to look at complicated 
upper level issues, we can focus on core basic network connectivity.
 
One thing the Exchange folks did that I am not in agreement with is if a DC is 
a config DC and is operating poorly Exchange will really avoid switching for 
config functionality if the ping is still there. That isn't a stateless 
connection so I can understand the reluctance but it can be a serious pain at 
times.
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Sunday, January 01, 2006 1:18 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] icmp's



Note Exchange doesn't take kindly to ICMP echo being disabled either. If Excha 
us nge can't ping a DC, DSACCESS does not see that DC unless you have specially 
configured it.

 

Which, I always thought was a pretty funny way of doing things anyway.  As you 
are well aware, Ping doesn't mean alive and healthy.  I know of many people who 
have spent hours to days troubleshooting a problem just to find that the 
machine that they first suspected as being the problem pinged just fine.  
Sadly, it was dead from the neck up and port 389 and 3268 were non-responsive 
(along with all of the other really important stuff).

 

Rick



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, January

Re: [ActiveDir] icmp's

2005-12-31 Thread Tom Kern
Thats it.

Isn't that the way its refered to in MS-speak?

I hope i didn't just make that up...
On 12/30/05, Brian Desmond [EMAIL PROTECTED] wrote:
presumably setting the scriptPath attribute on accounts...Thanks,Brian Desmond
[EMAIL PROTECTED]c - 312.731.3132From: [EMAIL PROTECTED] on behalf of Al Mulnick
Sent: Fri 12/30/2005 8:13 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] icmp'sWhen you say legacy way, what does that mean exactly?
On 12/30/05, Tom Kern [EMAIL PROTECTED] wrote: would this also affect clients from getting logon scripts? and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's.
 Thanks again On 12/30/05, Brian Desmond [EMAIL PROTECTED]  wrote: You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients.
 The rules look something like this: access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echo access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply
 Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network.
 Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 
 From: [EMAIL PROTECTED] on behalf of Tom Kern Sent: Fri 12/30/2005 9:25 AM To: activedirectory
 Subject: [ActiveDir] icmp's What affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest? any? I know clients ping dc's to see which responds first and later ping dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients?
 I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was wondering if thats something i should worry about in a win2k network.
 Thanks


Re: [ActiveDir] icmp's

2005-12-30 Thread beads

Tom;

Two things. First, if your network team
is specifically blocking all ICMP traffic its just not going to get there
regardless if its on VLAN or straight LAN traffic. You might suggest that
they allow ECHO ICMP instead of just blocking all ICMP. Second, to really
test where the blockage is at try using TRACERT. That should at least show
you how far the traffic is getting before being blocked. The error message
does appear (without more information) that this is indeed a bit aggressive
in the management department. You may also want to test your LDAP traffic
for passthru as well as the clients will eventually find the 'right' DC
via LDAP as well if they can't find ICMP traffic, as I understand the packet
logs. I may be wrong so feel free to correct me if I am misinterpreting
something. ;)







The contents contain privileged and/or confidential information intended
for the named recipient of this email. ETSI (Employee Technology Solutions,
Inc.) does not warrant that the contents of any electronically transmitted
information will remain confidential. If the reader of this email is not
the intended recipient you are hereby notified that any use, reproduction,
disclosure or distribution of the information contained in the email in
error, please reply to us immediately and delete the document. 

Viruses, Malware, Phishing and other known and unknown electronic threats:
It is the recipient/client's duties to perform virus scans and otherwise
test the information provided before loading onto any computer system.
No warranty is made that this material is free from computer virus or any
other defect.

Any loss/damage incurred by using this material is not the sender's responsibility.
Liability will be limited to resupplying the material.






Tom Kern [EMAIL PROTECTED]

Sent by: [EMAIL PROTECTED]
12/30/2005 08:25 AM



Please respond to
ActiveDir@mail.activedir.org





To
activedirectory ActiveDir@mail.activedir.org


cc



Subject
[ActiveDir] icmp's








What affect would blocking icmp packets on all vlans have
on win2k/xp client logons in a win2k forest?
any?

I know clients ping dc's to see which responds first and
later ping dc's to determine round trip time for GPO processing, but would
blocking icmp's have any adverse affects on clients?
I only ask because my corp blocks icmp's on all our vlans
and i get a lot of event id 1000 from Usernev with error code of 59 which
when i looked up, refers to network connectivity issues. i think this event
id is related to the fact we block icmp packets and i was wondering if
thats something i should worry about in a win2k network. 
Thanks


Message scanned by TrendMicro



Message scanned by TrendMicro

Re: [ActiveDir] icmp's

2005-12-30 Thread Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]

Group policy issues.

On the XP sp2 machines if you enable the firewall but allow 445 
traffic... merely enabling 445 with also allow ICMP.

Product team did this because they need it for group policy.

See discussion on focusonms listserve way back when XP sp2 first came out.

[Fire up your firewall and in the advanced window you can see it too]

Tom Kern wrote:

What affect would blocking icmp packets on all vlans have on win2k/xp 
client logons in a win2k forest?

any?
 
I know clients ping dc's to see which responds first and later ping 
dc's to determine round trip time for GPO processing, but would 
blocking icmp's have any adverse affects on clients?
I only ask because my corp blocks icmp's on all our vlans and i get a 
lot of event id 1000 from Usernev with error code of 59 which when i 
looked up, refers to network connectivity issues. i think this event 
id is related to the fact we block icmp packets and i was wondering if 
thats something i should worry about in a win2k network.

Thanks


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/


Re: [ActiveDir] icmp's

2005-12-30 Thread Tom Kern
All icmp traffic is being blocked between clients and DC's by a PIX firewall.

I just want to know how this will affect client logons.

I don't use the XP sp2 FW.

I'm not sure I understand Beads comment about blocking it on a straight lan.
How can you block traffic on a non segmented lan?
something has to be blocking the traffic on a L3 switch/router or on a firewall sitting between networks or vlans, etc.
we don't use personal sw firewalls here.

anyway, what i really would like to know is will blocking icmps om a pix fw between clients and DC's affect client logons or GPO processing?

Thanks a lot
On 12/30/05, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote:
Group policy issues.On the XP sp2 machines if you enable the firewall but allow 445traffic... merely enabling 445 with also allow ICMP.
Product team did this because they need it for group policy.See discussion on focusonms listserve way back when XP sp2 first came out.[Fire up your firewall and in the advanced window you can see it too]
Tom Kern wrote: What affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest? any? I know clients ping dc's to see which responds first and later ping
 dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients? I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i
 looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was wondering if thats something i should worry about in a win2k network.
 ThanksList info : http://www.activedir.org/List.aspxList FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/


RE: [ActiveDir] icmp's

2005-12-30 Thread Sullivan Tim
You'll break GPO's.

We block ICMP to all VLAN's except to our management VLAN (where the DC's roam).

Tim



From: [EMAIL PROTECTED] on behalf of Tom Kern
Sent: Fri 12/30/2005 9:27 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] icmp's


All icmp traffic is being blocked between clients and DC's by a PIX firewall.
 
I just want to know how this will affect client logons.
 
I don't use the XP sp2 FW.
 
I'm not sure I understand Beads comment about blocking it on a straight lan.
How can you block traffic on a non segmented lan?
something has to be blocking the traffic on a L3 switch/router or on a firewall 
sitting between networks or vlans, etc.
we don't use personal sw firewalls here.
 
anyway, what i really would like to know is will blocking icmps om a pix fw 
between clients and DC's affect client logons or GPO processing?
 
Thanks a lot

 
On 12/30/05, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] 
wrote: 

Group policy issues.

On the XP sp2 machines if you enable the firewall but allow 445
traffic... merely enabling 445 with also allow ICMP. 
Product team did this because they need it for group policy.

See discussion on focusonms listserve way back when XP sp2 first came 
out.

[Fire up your firewall and in the advanced window you can see it too] 

Tom Kern wrote:

 What affect would blocking icmp packets on all vlans have on win2k/xp
 client logons in a win2k forest?
 any?

 I know clients ping dc's to see which responds first and later ping 
 dc's to determine round trip time for GPO processing, but would
 blocking icmp's have any adverse affects on clients?
 I only ask because my corp blocks icmp's on all our vlans and i get a
 lot of event id 1000 from Usernev with error code of 59 which when i 
 looked up, refers to network connectivity issues. i think this event
 id is related to the fact we block icmp packets and i was wondering if
 thats something i should worry about in a win2k network. 
 Thanks

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/



winmail.dat

RE: [ActiveDir] icmp's

2005-12-30 Thread David Adner



You'll need to disable Slow Link Detection. You want 
to do this before disabling ICMP since once it's disabled the clients won't be 
able to process GPO's anymore (until Slow Link Detection is disabled). If 
you've already disabled ICMP then you'll need some alternate method of changing 
the Registry on the clients. Do a search at search.microsoft.com and 
you'll get several hits that discuss this.

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Tom 
  KernSent: Friday, December 30, 2005 8:25 AMTo: 
  activedirectorySubject: [ActiveDir] icmp's
  
  What affect would blocking icmp packets on all vlans have on win2k/xp 
  client logons in a win2k forest?
  any?
  
  I know clients ping dc's to see which responds first and later ping dc's 
  to determine round trip time for GPO processing, but would blocking icmp's 
  have any adverse affects on clients?
  I only ask because my corp blocks icmp's on all our vlans and i get a lot 
  of event id 1000 from Usernev with error code of 59 which when i looked up, 
  refers to network connectivity issues. i think this event id is related to the 
  fact we block icmp packets and i was wondering if thats something i should 
  worry about in a win2k network. 
  Thanks


RE: [ActiveDir] icmp's

2005-12-30 Thread Darren Mar-Elia



Right. No ICMP, no GP Processing. Check out my site as I 
have a discussion on this. Go to http://www.gpoguy.com/faqs.htmand 
search on "slow link".

Note that even restricted ICMP breaks GP processing. That 
is, if you were to restrict ICMP packet size to something less than 2048 bytes, 
GP processing will still break unless you modify the packet size that Windows 
uses (see http://support.microsoft.com/default.aspx?scid=kb;en-us;816045). 



From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of David 
AdnerSent: Friday, December 30, 2005 7:41 AMTo: 
ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] 
icmp's

You'll need to disable Slow Link Detection. You want 
to do this before disabling ICMP since once it's disabled the clients won't be 
able to process GPO's anymore (until Slow Link Detection is disabled). If 
you've already disabled ICMP then you'll need some alternate method of changing 
the Registry on the clients. Do a search at search.microsoft.com and 
you'll get several hits that discuss this.

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Tom 
  KernSent: Friday, December 30, 2005 8:25 AMTo: 
  activedirectorySubject: [ActiveDir] icmp's
  
  What affect would blocking icmp packets on all vlans have on win2k/xp 
  client logons in a win2k forest?
  any?
  
  I know clients ping dc's to see which responds first and later ping dc's 
  to determine round trip time for GPO processing, but would blocking icmp's 
  have any adverse affects on clients?
  I only ask because my corp blocks icmp's on all our vlans and i get a lot 
  of event id 1000 from Usernev with error code of 59 which when i looked up, 
  refers to network connectivity issues. i think this event id is related to the 
  fact we block icmp packets and i was wondering if thats something i should 
  worry about in a win2k network. 
  Thanks


RE: [ActiveDir] icmp's

2005-12-30 Thread Brian Desmond
You need to enable ICMP echo source clients dest dc's, and icmp echo-reply 
source dc's dest clients.
 
The rules look something like this:
 
access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers 
echo
 
access-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any 
echo-reply
 
Have your network people considered rate-limiting ICMP packets rather than 
shutting them down all together. IMHO that's the correct way to handle this. 
Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are 
necessary pieces of a network.
 
Thanks,
Brian Desmond
[EMAIL PROTECTED]
 
c - 312.731.3132



From: [EMAIL PROTECTED] on behalf of Tom Kern
Sent: Fri 12/30/2005 9:25 AM
To: activedirectory
Subject: [ActiveDir] icmp's


What affect would blocking icmp packets on all vlans have on win2k/xp client 
logons in a win2k forest?
any?
 
I know clients ping dc's to see which responds first and later ping dc's to 
determine round trip time for GPO processing, but would blocking icmp's have 
any adverse affects on clients?
I only ask because my corp blocks icmp's on all our vlans and i get a lot of 
event id 1000 from Usernev with error code of 59 which when i looked up, refers 
to network connectivity issues. i think this event id is related to the fact we 
block icmp packets and i was wondering if thats something i should worry about 
in a win2k network. 
Thanks
winmail.dat

Re: [ActiveDir] icmp's

2005-12-30 Thread Tom Kern
would this also affect clients from getting logon scripts?
and when i say logon scripts, i mean the legacy way of distributing them, NOT thru GPO's.

Thanks again
On 12/30/05, Brian Desmond [EMAIL PROTECTED] wrote:
You need to enable ICMP echo source clients dest dc's, and icmp echo-reply source dc's dest clients.
The rules look something like this:access-list DC_VLAN_OUT line 1 permit icmp any object-group domain_controllers echoaccess-list DC_VLAN_IN line 1 permit icmp object-group domain_controllers any echo-reply
Have your network people considered rate-limiting ICMP packets rather than shutting them down all together. IMHO that's the correct way to handle this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are necessary pieces of a network.
Thanks,Brian Desmond[EMAIL PROTECTED]c - 312.731.3132From: 
[EMAIL PROTECTED] on behalf of Tom KernSent: Fri 12/30/2005 9:25 AMTo: activedirectorySubject: [ActiveDir] icmp'sWhat affect would blocking icmp packets on all vlans have on win2k/xp client logons in a win2k forest?
any?I know clients ping dc's to see which responds first and later ping dc's to determine round trip time for GPO processing, but would blocking icmp's have any adverse affects on clients?I only ask because my corp blocks icmp's on all our vlans and i get a lot of event id 1000 from Usernev with error code of 59 which when i looked up, refers to network connectivity issues. i think this event id is related to the fact we block icmp packets and i was wondering if thats something i should worry about in a win2k network.
Thanks


RE: [ActiveDir] icmp's

2005-12-30 Thread Brian Desmond
Not likely.
 
Thanks,
Brian Desmond
[EMAIL PROTECTED]
 
c - 312.731.3132



From: [EMAIL PROTECTED] on behalf of Tom Kern
Sent: Fri 12/30/2005 3:36 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] icmp's


would this also affect clients from getting logon scripts?
and when i say logon scripts, i mean the legacy way of distributing them, NOT 
thru GPO's.
 
Thanks again

 
On 12/30/05, Brian Desmond [EMAIL PROTECTED] wrote: 

You need to enable ICMP echo source clients dest dc's, and icmp 
echo-reply source dc's dest clients.

The rules look something like this:

access-list DC_VLAN_OUT line 1 permit icmp any object-group 
domain_controllers echo

access-list DC_VLAN_IN line 1 permit icmp object-group 
domain_controllers any echo-reply 

Have your network people considered rate-limiting ICMP packets rather 
than shutting them down all together. IMHO that's the correct way to handle 
this. Ping (echo, echo-reply) and traceroute (traceroute, time-exceeded) are 
necessary pieces of a network. 

Thanks,
Brian Desmond
[EMAIL PROTECTED]

c - 312.731.3132



From: [EMAIL PROTECTED] on behalf of Tom Kern
Sent: Fri 12/30/2005 9:25 AM
To: activedirectory
Subject: [ActiveDir] icmp's


What affect would blocking icmp packets on all vlans have on win2k/xp 
client logons in a win2k forest? 
any?

I know clients ping dc's to see which responds first and later ping 
dc's to determine round trip time for GPO processing, but would blocking icmp's 
have any adverse affects on clients?
I only ask because my corp blocks icmp's on all our vlans and i get a 
lot of event id 1000 from Usernev with error code of 59 which when i looked up, 
refers to network connectivity issues. i think this event id is related to the 
fact we block icmp packets and i was wondering if thats something i should 
worry about in a win2k network. 
Thanks




winmail.dat