|
Keep in mind, there is a reason that UDP was chosen for the
standard. It is a lot lighter/skinnier and in probably 95%+ of the cases it
works perfectly fine. You don't necessarily want to fatten up all of the traffic
for everyone to fight an occasional problem. The problems tend to come in from
misconfigurations of network devices or because people get overzealous tend to
think of UDP as unimportant traffic (if its important, it will use TCP!!) so
aren't afraid to configure devices to quickly drop it. That is old thinking
completely due to old crappy networks. I fully expect to see more and more use
of UDP especially in internal networks as the networking tech get more and
more stable. The loss of the overhead required for maintaining the sessions is a
good thing. It means less processing power for processing the extra info,
less memory resources for maintaining all of the TCP connection state
info, and less network traffic due to less data to go over the
wire.
Think of it this way, right now AD works by sending a basic
simple string stream across for most LDAP ops. Consider that someone decides
that it would be much better if all info was XML encapsulated because it is was
less likely to be confused or something like that and you get to a near doubling
in the bytes on the wire and anything asking for the info has to now deal with
all of the XML. I point this specific item out because there is a case where
this occurs with AD Data that is returned over LDAP for replication metadata
attributes. It is much smaller and tighter coming over as a binary pack, though
definitely not as easy to use for some people.
I would be highly surprised if Microsoft changed this
across the board for all kerberos packets instead of possibly just lowering the
packetsize "again"[1] when it happens (but not to 1). What would be really cool
is if they tried to work out the logic for it to figure out that is happening
when a client is trying to logon and automatically kick the value down a little
at a time until it works. That could probably all be done in far less time than
it takes for people to spend 30 minutes logging on and then admins spending
hours or days working out why.
I have hit this twice in the real world. The first time was
with some very overzealous firmware settings on Cisco load balancers (CSMs)
because "UDP traffic isn't important" which Cisco corrected with a patch
and once when we had a DC that had somehow gotten the wrong network card
device driver installed on it and it was dorking up all sorts of things.
joe
[1] It
went from 2000 to under 1500 in 2K to K3.
Something I wish they
did when the product was released J
Todd
From: Olivarez,
Sergio J Mr CTNOSC/GD-NS [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 14, 2006 5:14
PM
To:
ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Communication
across a trust...with firewalls
Rocky, the reg hack
that is referenced in Jeff’s response is one that I have seen Microsoft highly
encourage and push towards customers. I’ve spoken to a couple of Microsoft
reps that say that this hack will be implemented in a future service pack\ patch
because of all the problems it alleviates. I really see no risk in making
this change, all it does is force Kerberos over TCP.
Thanks... ... ...
...
Sergio J. Olivarez -
Contractor
GD-NS
From: Jeff
Salisbury [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 14, 2006 2:23
PM
To:
ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Communication
across a trust...with firewalls
Rocky - This article
explains why the fragmented UDP packets cause problems: http://support.microsoft.com/?id=244474 and
how to modify the registry to force TCP. We run into this periodically,
especially with users running a VPN tunnel across their home wireless network.
Jeff
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Rocky
Habeeb
Sent: Tuesday, March
14, 2006 12:18 PM
To:
ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Communication
across a trust...with firewalls
So .... why does fragmentation cause a
problem? Packets are fragmented all the time in network traffic but
stuff still works. Are you saying credentialling packets can't be
fragmented?
___________________________________
-----Original
Message-----
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Myrick, Todd (NIH/CC/DNA)
[E]
Sent: Tuesday, March
14, 2006 2:55 PM
To:
ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Communication
across a trust...with firewalls
You might also want
to investigate if you are using TCP or UDP packets with your authentication
request. By default Kerberos uses UDP, so a lot of firewalls will
fragment the packets and cause authentication issues.
Todd
Myrick
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Almeida Pinto, Jorge
de
Sent: Tuesday, March 14,
2006 2:47 PM
To:
ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Communication
across a trust...with firewalls
lets say the
structure is:
CLIENT-DOMAIN_A
..... DC-DOMAIN_A
...... DC-DOMAIN_B
...... MEMBERSRV-DOMAIN_B
if NTLM is used the order of
authentication is:
(1) CLIENT-DOMAIN_A wants to
access MEMBERSRV-DOMAIN_B
(2)
CLIENT-DOMAIN_A connects
to MEMBERSRV-DOMAIN_B
(3) MEMBERSRV-DOMAIN_B
connects to DC-DOMAIN_B and asks do you know:
CLIENT-DOMAIN_A
(4) DC-DOMAIN_B says NO, but I
do trust DOMAIN_A. Let me check.
(5) DC-DOMAIN_B connects
to DC-DOMAIN_A and asks do you know:
CLIENT-DOMAIN_A
(6) DC-DOMAIN_A says: yes,
it's OK
(7) DC-DOMAIN_B sets up an
access token for domain B for CLIENT-DOMAIN_A.
(8) CLIENT-DOMAIN_A accesses
MEMBERSRV-DOMAIN_B
if KERBEROS is used the
order of authentication is:
(1) CLIENT-DOMAIN_A wants to
access MEMBERSRV-DOMAIN_B
(2)
CLIENT-DOMAIN_A connects to DC-DOMAIN_A and asks for a ticket to
access MEMBERSRV-DOMAIN_B
(3) DC-DOMAIN_A says: let me
check, just a sec.
(4) DC-DOMAIN_A says: that
server does not exist within the domain or the forest. However I do have a
trust with DOMAIN_B. Go to DC-DOMAIN_B
(5) CLIENT-DOMAIN_A connects
to DC-DOMAIN_B and asks for a ticket to access
MEMBERSRV-DOMAIN_B
(6) DC-DOMAIN_B says: let me
check, just a sec.
(7) DC-DOMAIN_B says: here's
your ticket and access token. have fun
(8) CLIENT-DOMAIN_A accesses
MEMBERSRV-DOMAIN_B
the problem is that only
DC-DOMAIN_A and DC-DOMAIN_B can communicate through the firewall with each
other. Other communication paths are not available or possible because of
the firewall configuration.
Met vriendelijke
groeten / Kind regards,
Ing. Jorge de
Almeida Pinto
Senior
Infrastructure Consultant
MVP Windows
Server - Directory Services
LogicaCMG
Nederland B.V. (BU RTINC Eindhoven)
(
Tel
: +31-(0)40-29.57.777
(
Mobile
:
+31-(0)6-26.26.62.80
*
E-mail
: [EMAIL PROTECTED]
From:
[EMAIL PROTECTED] on behalf of
[EMAIL PROTECTED]
Sent:
Tue 2006-03-14 16:35
To:
ActiveDir@mail.activedir.org
Subject: [ActiveDir] Communication
across a trust...with firewalls
Within a domain, when a user’s
credentials are presented to a member server, that member server
communicates with the domain controller to validate the
creds.
We have a cross-forest
(cross–company; a divestiture) trust set up that we are testing. A
member server in the other forest/domain and across the firewall is having
trouble authenticating credentials from our domain. Their DC works
fine. Ports on the firewall are only opened for the two domain
controllers (one on each side).
Here’s the question: in
order to validate the “foreign” credentials, should the member server be
looking first to its own DC, or is it trying to cross the firewall to find
our DC? Based in the preliminary traffic sampling so far, I think
that’s what is happening. Is that normal/expected
behavior?
TIA,
AL
Al
Maurer
Service
Manager, Naming and Authentication Services
IT | Information
Technology
Agilent Technologies
(719) 590-2639; Telnet
590-2639
http://activedirectory.it.agilent.com
Confidential
This e-mail
and any files transmitted with it are the property
of Belkin Corporation
and/or its affiliates, are confidential,
and are intended solely for the use
of the individual or
entity to whom this e-mail is addressed. If you
are not one
of the named recipients or otherwise have reason to
believe
that you have received this e-mail in error, please notify
the
sender and delete this message immediately from your computer.
Any
other use, retention, dissemination, forwarding, printing
or copying of this
e-mail is strictly prohibited.
|
