Forum Search:
Forum.Brain-Cluster.com: Brain Cluster Technical Forum
Ultimate forum for Technical Discussions

Home » Microsoft » Windows Server » Active Directory » ADAM handshaking very slow in a DMZ
ADAM handshaking very slow in a DMZ [message #159727] Wed, 05 August 2009 07:53 Go to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
I've been struggling with this for a couple weeks trying to troubleshoot it
and it's not making sense to me. This may be a bit of a ramble and I apolize
for some unorganized thoughts here.

I've got a server in a DMZ that has a web service which uses forms based
authentication to verify user credentials against ADAM. That ADAM server is
internal. Port 636 is open between the DMZ web server and the ADAM server.

The ADAM server is a member of our internal domain.

What I'm seeing is that the web server is when the web service is initially
hit in the morning, it takes about 65 seconds to complete handshaking with
ADAM on the verification of the cert. Users enter their credentials and then
wait 65 seconds before being shown the page after authentication.

If I install a test instance internally of this same web service, it takes
no more than 5 seconds in the same scenario.

Very odd. So, we look at the firewall and sniffer. I see no additional
ports or activity that would reflect that activity is getting blocked.

So, I fire up LDP, make the conneciton to the host, bind. Instantaneous
response. No pause at all. Speed is the same with LDP both on the DMZ and
the internal test box. So, everything looks good to me.

I run netstat -noa and see that 3 connections are made by IIS to the adam
box when the web app initializes. Very strange. Only 1 when using LDP.

However, I still see a huge difference in time on the internal server versus
the external server.

The web form is just using a simple form for login. The connection string
the developer used is pretty standard. We've tried both
LDAP://server.domain:636 and LDAP://server.domain

No difference in speed.

What is odd is... normally, I think we'd have some underlying network issue.
However, LDP reflects that it can't be. I have instant browse access to the
ADAM structure when using LDP and see no differences in speed between either
server.

It's only when this web application initially fires up in the morning do we
see this. After initially being used, the rest of the day, response time for
credentials seems to be nearly identical to that of the internal server.

When I use wireshark, I'm not seeing any difference in activity on the box.
What I do see is that the SSL handshaking takes a long time when using the
web app (uses .net framework 2.0).

So, this really confuses me. I see nearly identical behavior on both the
internal and external boxes. However, the big difference is in speed on
initial connection to ADAM from the DMZ web server.

Why would this initial connection to ADAM take so long in a DMZ as opposed
to an internal network?

Thank you

Ted
Re: ADAM handshaking very slow in a DMZ [message #159761 is a reply to message #159727] Thu, 06 August 2009 09:35 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi,

If you look at the network trace of a slow connection from the DMZ can you
spot
which *part* of the packet exchange is lagged as compared to a trace from
the DMS
that is faster?

Thanks
Lee Flight


"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:D723AE38-46F4-4607-A961-30DCAE31B128@microsoft.com...
> I've been struggling with this for a couple weeks trying to troubleshoot
> it
> and it's not making sense to me. This may be a bit of a ramble and I
> apolize
> for some unorganized thoughts here.
>
> I've got a server in a DMZ that has a web service which uses forms based
> authentication to verify user credentials against ADAM. That ADAM server
> is
> internal. Port 636 is open between the DMZ web server and the ADAM
> server.
>
> The ADAM server is a member of our internal domain.
>
> What I'm seeing is that the web server is when the web service is
> initially
> hit in the morning, it takes about 65 seconds to complete handshaking with
> ADAM on the verification of the cert. Users enter their credentials and
> then
> wait 65 seconds before being shown the page after authentication.
>
> If I install a test instance internally of this same web service, it takes
> no more than 5 seconds in the same scenario.
>
> Very odd. So, we look at the firewall and sniffer. I see no additional
> ports or activity that would reflect that activity is getting blocked.
>
> So, I fire up LDP, make the conneciton to the host, bind. Instantaneous
> response. No pause at all. Speed is the same with LDP both on the DMZ
> and
> the internal test box. So, everything looks good to me.
>
> I run netstat -noa and see that 3 connections are made by IIS to the adam
> box when the web app initializes. Very strange. Only 1 when using LDP.
>
> However, I still see a huge difference in time on the internal server
> versus
> the external server.
>
> The web form is just using a simple form for login. The connection string
> the developer used is pretty standard. We've tried both
> LDAP://server.domain:636 and LDAP://server.domain
>
> No difference in speed.
>
> What is odd is... normally, I think we'd have some underlying network
> issue.
> However, LDP reflects that it can't be. I have instant browse access to
> the
> ADAM structure when using LDP and see no differences in speed between
> either
> server.
>
> It's only when this web application initially fires up in the morning do
> we
> see this. After initially being used, the rest of the day, response time
> for
> credentials seems to be nearly identical to that of the internal server.
>
> When I use wireshark, I'm not seeing any difference in activity on the
> box.
> What I do see is that the SSL handshaking takes a long time when using the
> web app (uses .net framework 2.0).
>
> So, this really confuses me. I see nearly identical behavior on both the
> internal and external boxes. However, the big difference is in speed on
> initial connection to ADAM from the DMZ web server.
>
> Why would this initial connection to ADAM take so long in a DMZ as opposed
> to an internal network?
>
> Thank you
>
> Ted
Re: ADAM handshaking very slow in a DMZ [message #159771 is a reply to message #159761] Fri, 07 August 2009 06:09 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
Hi Lee and thanks. I spent several hours going over this and doing more
sniffing to make sure. I didn't want to give you any incorrect information.

I think it would be better for me to provide the wireshark details than
trusting myself with the ability to properly describe this.

I would like to add I've done several hours of testing back and forth.
During the time when the web app is establishing a conneciton to the ADAM
server, I don't see any different attempted port activity than port 636. I
don't see any denies nor additional activity at the firewall and I'm not
seeing it locally with WireShark.

Below is a CSV output of the activity on the IIS server in the DMZ
connecting to the ADAM server. All data is filtered by host and destination
being either a source or destination and by filtering port 636.

"497","52.854993","172.16.0.36","10.128.2.38","TCP", "cognex-insight > ldaps
[SYN] Seq=0 Win=65535 Len=0 MSS=1460"
"499","52.856578","172.16.0.36","10.128.2.38","TCP", "cognex-insight > ldaps
[ACK] Seq=1 Ack=1 Win=65535 Len=0"
"500","52.859660","172.16.0.36","10.128.2.38","SSLv2 ","Client Hello"
"503","52.861512","172.16.0.36","10.128.2.38","TCP", "cognex-insight > ldaps
[ACK] Seq=40 Ack=2761 Win=65535 Len=0"
"506","52.862277","172.16.0.36","10.128.2.38","TCP", "cognex-insight > ldaps
[ACK] Seq=40 Ack=4997 Win=65535 Len=0"
"634","72.906563","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"636","72.916074","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"638","72.924412","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"641","72.926101","172.16.0.36","10.128.2.38","TCP", "cognex-insight > ldaps
[ACK] Seq=437 Ack=7313 Win=65535 Len=0"
"642","72.931050","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [SYN]
Seq=0 Win=65535 Len=0 MSS=1460"
"644","72.931452","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1 Ack=1 Win=65535 Len=0"
"645","72.932213","172.16.0.36","10.128.2.38","SSLv2 ","Client Hello"
"648","72.933604","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=40 Ack=2761 Win=65535 Len=0"
"651","72.934195","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=40 Ack=4997 Win=65535 Len=0"
"785","92.859324","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"787","92.864444","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"789","92.865831","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"791","92.868324","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"793","92.869298","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"795","92.870374","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"797","92.871066","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"800","92.877282","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=10079 Win=65535 Len=0"
"803","92.877514","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=12839 Win=65535 Len=0"
"806","92.877755","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=15599 Win=65535 Len=0"
"809","92.877989","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=18359 Win=65535 Len=0"
"812","92.878212","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=21119 Win=65535 Len=0"
"815","92.878452","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=23879 Win=65535 Len=0"
"819","92.878826","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=28019 Win=65535 Len=0"
"822","92.879030","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=30779 Win=65535 Len=0"
"825","92.879268","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=33539 Win=65535 Len=0"
"828","92.879499","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=36299 Win=65535 Len=0"
"831","92.879737","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=39059 Win=65535 Len=0"
"835","92.880104","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=43199 Win=65535 Len=0"
"838","92.880314","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=45959 Win=65535 Len=0"
"841","92.880554","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=48719 Win=65535 Len=0"
"844","92.880782","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=51479 Win=65535 Len=0"
"847","92.881021","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=54239 Win=65535 Len=0"
"850","92.881252","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=56999 Win=65535 Len=0"
"853","92.881513","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=59759 Win=65535 Len=0"
"856","92.881714","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=62519 Win=65535 Len=0"
"859","92.881916","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
Seq=1104 Ack=64846 Win=65535 Len=0"
"860","92.911437","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps [SYN]
Seq=0 Win=65535 Len=0 MSS=1460"
"862","92.911917","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps [ACK]
Seq=1 Ack=1 Win=65535 Len=0"
"863","92.912532","172.16.0.36","10.128.2.38","SSLv2 ","Client Hello"
"866","92.914023","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps [ACK]
Seq=40 Ack=2761 Win=65535 Len=0"
"869","92.914686","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps [ACK]
Seq=40 Ack=4997 Win=65535 Len=0"
"997","112.843447","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"999","112.849605","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1001","112.852177","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1003","112.889895","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1005","112.893510","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1007","112.902756","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1009","112.903546","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1010","112.903851","172.16.0.36","10.128.2.38","TCP ","rdrmshc > ldaps [FIN,
ACK] Seq=609 Ack=5455 Win=65077 Len=0"
"1012","112.904410","172.16.0.36","10.128.2.38","TCP ","rdrmshc > ldaps [ACK]
Seq=610 Ack=5456 Win=65077 Len=0"
"1014","112.908610","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1016","112.950118","172.16.0.36","10.128.2.38","TCP ","asprovatalk > ldaps
[SYN] Seq=0 Win=65535 Len=0 MSS=1460"
"1018","112.950635","172.16.0.36","10.128.2.38","TCP ","asprovatalk > ldaps
[ACK] Seq=1 Ack=1 Win=65535 Len=0"
"1019","112.951269","172.16.0.36","10.128.2.38","SSLv2 ","Client Hello"
"1022","112.952558","172.16.0.36","10.128.2.38","TCP ","asprovatalk > ldaps
[ACK] Seq=40 Ack=2761 Win=65535 Len=0"
"1025","112.953207","172.16.0.36","10.128.2.38","TCP ","asprovatalk > ldaps
[ACK] Seq=40 Ack=4997 Win=65535 Len=0"
"1028","113.122915","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps [ACK]
Seq=1816 Ack=65639 Win=64742 Len=0"
"1157","132.874402","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"1159","132.879552","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1161","132.881669","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1163","132.883543","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1165","132.885936","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1185","133.028979","172.16.0.36","10.128.2.38","TCP ","asprovatalk > ldaps
[ACK] Seq=347 Ack=5151 Win=65381 Len=0"
"1186","133.029003","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps [ACK]
Seq=2128 Ack=66610 Win=65535 Len=0"
"1194","133.782678","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1195","133.782997","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps [FIN,
ACK] Seq=2160 Ack=66610 Win=65535 Len=0"
"1198","133.783304","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps [ACK]
Seq=2161 Ack=66611 Win=65535 Len=0"
"1358","136.002408","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1360","136.003872","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1362","136.004823","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"1399","136.200853","172.16.0.36","10.128.2.38","TCP ","cognex-insight >
ldaps [ACK] Seq=835 Ack=8411 Win=64437 Len=0"


This is the CSV output of the activity on the test web server on the
internal network connecting to the same internal ADAM server:

"1674","64.218905","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[SYN] Seq=0 Win=65535 Len=0 MSS=1460"
"1676","64.219399","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=1 Ack=1 Win=65535 Len=0"
"1677","64.221267","10.128.0.22","10.128.2.38","SSLv2 ","Client Hello"
"1680","64.222750","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=49 Ack=2921 Win=65535 Len=0"
"1683","64.223225","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=49 Ack=4997 Win=65535 Len=0"
"1684","64.242081","10.128.0.22","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"1686","64.285980","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1688","64.288359","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1691","64.289195","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=446 Ack=7313 Win=65535 Len=0"
"1692","64.291833","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1694","64.293835","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1696","64.294717","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1698","64.295741","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1700","64.296618","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1712","64.300958","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=1185 Ack=25609 Win=58235 Len=0"
"1725","64.302003","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=1185 Ack=43129 Win=40715 Len=0"
"1726","64.302402","10.128.0.22","10.128.2.38","TCP", "[TCP Window Update]
aeroflight-ads > ldaps [ACK] Seq=1185 Ack=43129 Win=44475 Len=0"
"1727","64.302470","10.128.0.22","10.128.2.38","TCP", "[TCP Dup ACK 1726#1]
aeroflight-ads > ldaps [ACK] Seq=1185 Ack=43129 Win=44475 Len=0"
"1728","64.302610","10.128.0.22","10.128.2.38","TCP", "[TCP Window Update]
aeroflight-ads > ldaps [ACK] Seq=1185 Ack=43129 Win=65535 Len=0"
"1742","64.304311","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=1185 Ack=62109 Win=55315 Len=0"
"1743","64.304417","10.128.0.22","10.128.2.38","TCP", "[TCP Window Update]
aeroflight-ads > ldaps [ACK] Seq=1185 Ack=62109 Win=59075 Len=0"
"1744","64.304651","10.128.0.22","10.128.2.38","TCP", "[TCP Dup ACK 1743#1]
aeroflight-ads > ldaps [ACK] Seq=1185 Ack=62109 Win=59075 Len=0"
"1745","64.304735","10.128.0.22","10.128.2.38","TCP", "[TCP Window Update]
aeroflight-ads > ldaps [ACK] Seq=1185 Ack=62109 Win=65535 Len=0"
"1750","64.305411","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=1185 Ack=67076 Win=65535 Len=0"
"1751","64.318335","10.128.0.22","10.128.2.38","TCP", "aeroflight-ret > ldaps
[SYN] Seq=0 Win=65535 Len=0 MSS=1460"
"1753","64.318809","10.128.0.22","10.128.2.38","TCP", "aeroflight-ret > ldaps
[ACK] Seq=1 Ack=1 Win=65535 Len=0"
"1754","64.319510","10.128.0.22","10.128.2.38","SSLv2 ","Client Hello"
"1757","64.321413","10.128.0.22","10.128.2.38","TCP", "aeroflight-ret > ldaps
[ACK] Seq=49 Ack=2921 Win=65535 Len=0"
"1760","64.322071","10.128.0.22","10.128.2.38","TCP", "aeroflight-ret > ldaps
[ACK] Seq=49 Ack=4997 Win=65535 Len=0"
"1761","64.323381","10.128.0.22","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"1763","64.328624","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1765","64.330377","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1767","64.336256","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1769","64.338357","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1771","64.341194","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1773","64.341843","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1774","64.342269","10.128.0.22","10.128.2.38","TCP", "aeroflight-ret > ldaps
[FIN, ACK] Seq=618 Ack=5455 Win=65077 Len=0"
"1775","64.345683","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1779","64.346335","10.128.0.22","10.128.2.38","TCP", "aeroflight-ret > ldaps
[ACK] Seq=619 Ack=5456 Win=65077 Len=0"
"1780","64.350186","10.128.0.22","10.128.2.38","TCP", "qt-serveradmin > ldaps
[SYN] Seq=0 Win=65535 Len=0 MSS=1460"
"1782","64.350670","10.128.0.22","10.128.2.38","TCP", "qt-serveradmin > ldaps
[ACK] Seq=1 Ack=1 Win=65535 Len=0"
"1783","64.351193","10.128.0.22","10.128.2.38","SSLv2 ","Client Hello"
"1786","64.352358","10.128.0.22","10.128.2.38","TCP", "qt-serveradmin > ldaps
[ACK] Seq=49 Ack=2921 Win=65535 Len=0"
"1789","64.353606","10.128.0.22","10.128.2.38","TCP", "qt-serveradmin > ldaps
[ACK] Seq=49 Ack=4997 Win=65535 Len=0"
"1790","64.355751","10.128.0.22","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"1792","64.360323","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1794","64.363160","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1796","64.364264","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1798","64.366519","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"1818","64.508644","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=2209 Ack=68840 Win=65535 Len=0"
"1820","64.508972","10.128.0.22","10.128.2.38","TCP", "qt-serveradmin > ldaps
[ACK] Seq=356 Ack=5151 Win=65381 Len=0"
"2005","66.462074","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"2007","66.464773","10.128.0.22","10.128.2.38","TLSv1 ","Application Data"
"2037","66.596971","10.128.0.22","10.128.2.38","TCP", "aeroflight-ads > ldaps
[ACK] Seq=2475 Ack=69055 Win=65320 Len=0"


When I use LDP, I nearly always get this same activity when using LDP to
test both on the internal and external IIS server
connecting to the internal ADAM server:

"167","25.488037","172.16.0.36","10.128.2.38","TCP", "udpradio > ldaps [SYN]
Seq=0 Win=65535 Len=0 MSS=1460"
"168","25.489597","10.128.2.38","172.16.0.36","TCP", "ldaps > udpradio [SYN,
ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1380"
"169","25.489611","172.16.0.36","10.128.2.38","TCP", "udpradio > ldaps [ACK]
Seq=1 Ack=1 Win=65535 Len=0"
"170","25.497812","172.16.0.36","10.128.2.38","SSLv2 ","Client Hello"
"171","25.499536","10.128.2.38","172.16.0.36","TCP", "[TCP segment of a
reassembled PDU]"
"172","25.499641","10.128.2.38","172.16.0.36","TCP", "[TCP segment of a
reassembled PDU]"
"173","25.499665","172.16.0.36","10.128.2.38","TCP", "udpradio > ldaps [ACK]
Seq=40 Ack=2761 Win=65535 Len=0"
"174","25.500205","10.128.2.38","172.16.0.36","TCP", "[TCP segment of a
reassembled PDU]"
"175","25.500287","10.128.2.38","172.16.0.36","TLSv1 ","Server Hello,
Certificate, Certificate Request, Server Hello Done"
"176","25.500320","172.16.0.36","10.128.2.38","TCP", "udpradio > ldaps [ACK]
Seq=40 Ack=4997 Win=65535 Len=0"
"177","25.512250","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
"178","25.517869","10.128.2.38","172.16.0.36","TLSv1 ","Change Cipher Spec,
Encrypted Handshake Message"
"179","25.635095","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"180","25.636463","10.128.2.38","172.16.0.36","TCP", "[TCP segment of a
reassembled PDU]"
"181","25.636543","10.128.2.38","172.16.0.36","TLSv1 ","Application Data"
"182","25.636559","172.16.0.36","10.128.2.38","TCP", "udpradio > ldaps [ACK]
Seq=301 Ack=7270 Win=65535 Len=0"
"184","25.932394","10.128.2.38","172.16.0.36","TCP", "[TCP Dup ACK 181#1]
ldaps > udpradio [ACK] Seq=7270 Ack=301 Win=65235 Len=0"
"231","33.367884","172.16.0.36","10.128.2.38","TLSv1 ","Application Data"
"232","33.369031","10.128.2.38","172.16.0.36","TLSv1 ","Application Data"
"233","33.536888","172.16.0.36","10.128.2.38","TCP", "udpradio > ldaps [ACK]
Seq=437 Ack=7313 Win=65492 Len=0"






"Lee Flight" wrote:

> Hi,
>
> If you look at the network trace of a slow connection from the DMZ can you
> spot
> which *part* of the packet exchange is lagged as compared to a trace from
> the DMS
> that is faster?
>
> Thanks
> Lee Flight
>
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:D723AE38-46F4-4607-A961-30DCAE31B128@microsoft.com...
> > I've been struggling with this for a couple weeks trying to troubleshoot
> > it
> > and it's not making sense to me. This may be a bit of a ramble and I
> > apolize
> > for some unorganized thoughts here.
> >
> > I've got a server in a DMZ that has a web service which uses forms based
> > authentication to verify user credentials against ADAM. That ADAM server
> > is
> > internal. Port 636 is open between the DMZ web server and the ADAM
> > server.
> >
> > The ADAM server is a member of our internal domain.
> >
> > What I'm seeing is that the web server is when the web service is
> > initially
> > hit in the morning, it takes about 65 seconds to complete handshaking with
> > ADAM on the verification of the cert. Users enter their credentials and
> > then
> > wait 65 seconds before being shown the page after authentication.
> >
> > If I install a test instance internally of this same web service, it takes
> > no more than 5 seconds in the same scenario.
> >
> > Very odd. So, we look at the firewall and sniffer. I see no additional
> > ports or activity that would reflect that activity is getting blocked.
> >
> > So, I fire up LDP, make the conneciton to the host, bind. Instantaneous
> > response. No pause at all. Speed is the same with LDP both on the DMZ
> > and
> > the internal test box. So, everything looks good to me.
> >
> > I run netstat -noa and see that 3 connections are made by IIS to the adam
> > box when the web app initializes. Very strange. Only 1 when using LDP.
> >
> > However, I still see a huge difference in time on the internal server
> > versus
> > the external server.
> >
> > The web form is just using a simple form for login. The connection string
> > the developer used is pretty standard. We've tried both
> > LDAP://server.domain:636 and LDAP://server.domain
> >
> > No difference in speed.
> >
> > What is odd is... normally, I think we'd have some underlying network
> > issue.
> > However, LDP reflects that it can't be. I have instant browse access to
> > the
> > ADAM structure when using LDP and see no differences in speed between
> > either
> > server.
> >
> > It's only when this web application initially fires up in the morning do
> > we
> > see this. After initially being used, the rest of the day, response time
> > for
> > credentials seems to be nearly identical to that of the internal server.
> >
> > When I use wireshark, I'm not seeing any difference in activity on the
> > box.
> > What I do see is that the SSL handshaking takes a long time when using the
> > web app (uses .net framework 2.0).
> >
> > So, this really confuses me. I see nearly identical behavior on both the
> > internal and external boxes. However, the big difference is in speed on
> > initial connection to ADAM from the DMZ web server.
> >
> > Why would this initial connection to ADAM take so long in a DMZ as opposed
> > to an internal network?
> >
> > Thank you
> >
> > Ted
>
>
>
Re: ADAM handshaking very slow in a DMZ [message #159823 is a reply to message #159771] Mon, 10 August 2009 03:37 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi

so looking at the problem trace you pick up (20.04s,19.93s,19.93s,19.75s)
so say 20s at each of the 4 points below. It also looks from your trace
sequence numbers (the first number on each line?) that there are ~128
packets not shown during each of those intervals what was happening there?
Noted also that the problem trace has 4 Client Hellos whereas "normal" trace
has 3.

Also your traces from the WWW server in both cases only show packets
with 10.128.2.38 (the intranet ADAM instance?) as destination.

Thanks
Lee Flight

"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:A7E4EE55-7641-4500-AF4E-A7E52C023ECB@microsoft.com...

> "506","52.862277","172.16.0.36","10.128.2.38","TCP", "cognex-insight >
> ldaps
> [ACK] Seq=40 Ack=4997 Win=65535 Len=0"
> "634","72.906563","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
> Key Exchange, Change Cipher Spec, Encrypted Handshake Message"

> "651","72.934195","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
> Seq=40 Ack=4997 Win=65535 Len=0"
> "785","92.859324","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
> Key Exchange, Change Cipher Spec, Encrypted Handshake Message"


> "869","92.914686","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps [ACK]
> Seq=40 Ack=4997 Win=65535 Len=0"
> "997","112.843447","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> Client
> Key Exchange, Change Cipher Spec, Encrypted Handshake Message"

> "1028","113.122915","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps
> [ACK]
> Seq=1816 Ack=65639 Win=64742 Len=0"
> "1157","132.874402","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> Client
> Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
Re: ADAM handshaking very slow in a DMZ [message #159831 is a reply to message #159823] Mon, 10 August 2009 06:04 Go to previous messageGo to next message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
The missing packets are LLC checks and other unrelated packets. Those all
appear to be normal. I just didn't want to clutter the post with those.

There's a second web application (on the same box) which queries SQL and
returns data to the user. This forms authentication piece just directs them
to that secondary web application once authentication is good.

What is confusing to me is the SSLv2 request and then the TLSv1 response.

From the point of sequest 631 and 651 ... between those two are just some
LLC checks... no TCP.

Yes, the 10.128.2.38 is the internal ADAM instance.

What's throwing me, and what I don't understand, is the 3 ports opened to
ADAM from the web server. Is this a result of the TCP DUP?

Ted

"Lee Flight" wrote:

> Hi
>
> so looking at the problem trace you pick up (20.04s,19.93s,19.93s,19.75s)
> so say 20s at each of the 4 points below. It also looks from your trace
> sequence numbers (the first number on each line?) that there are ~128
> packets not shown during each of those intervals what was happening there?
> Noted also that the problem trace has 4 Client Hellos whereas "normal" trace
> has 3.
>
> Also your traces from the WWW server in both cases only show packets
> with 10.128.2.38 (the intranet ADAM instance?) as destination.
>
> Thanks
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:A7E4EE55-7641-4500-AF4E-A7E52C023ECB@microsoft.com...
>
> > "506","52.862277","172.16.0.36","10.128.2.38","TCP", "cognex-insight >
> > ldaps
> > [ACK] Seq=40 Ack=4997 Win=65535 Len=0"
> > "634","72.906563","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>
> > "651","72.934195","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps [ACK]
> > Seq=40 Ack=4997 Win=65535 Len=0"
> > "785","92.859324","172.16.0.36","10.128.2.38","TLSv1 ","Certificate, Client
> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>
>
> > "869","92.914686","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps [ACK]
> > Seq=40 Ack=4997 Win=65535 Len=0"
> > "997","112.843447","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> > Client
> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>
> > "1028","113.122915","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps
> > [ACK]
> > Seq=1816 Ack=65639 Win=64742 Len=0"
> > "1157","132.874402","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> > Client
> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>
>
>
Re: ADAM handshaking very slow in a DMZ [message #159839 is a reply to message #159831] Mon, 10 August 2009 07:10 Go to previous messageGo to next message
Lee Flight  is currently offline Lee Flight  United Kingdom
Messages: 392
Registered: July 2009
Senior Member
Hi

as to the 3 ports or perhaps the 3 client hellos then that does not surprise
me so much as it will depend on how the application is written so it's
common
to have an application that uses a reader account to match a user in the
directory
and return say the distinguishedName of the user and then have the
application
re-bind using that distinguishedName and the user supplied password to
authenticate
the user. Hard to say without access to the application source.

However I'm now wondering that as your application does nothing on the wire
during those 20sec delays what the application is doing and perhaps the SQL
instance is the clue... something I have seen with Microsoft Sharepoint is
that
the first user of an intranet Sharepoint during a working day gets a delayed
response
and that subsequent responses are slicker until the next morning - the cause
in that
case was that the application connection to the backend database (SQL) idles
out and when the connection is re-established for the first user there is an
overhead/delay in setting up the DB connection...not sure if that would fit
with your application architecture?

Lee Flight

"Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
news:888E5BAF-3EE8-4EAE-8AC3-0F26A020DD52@microsoft.com...
> The missing packets are LLC checks and other unrelated packets. Those all
> appear to be normal. I just didn't want to clutter the post with those.
>
> There's a second web application (on the same box) which queries SQL and
> returns data to the user. This forms authentication piece just directs
> them
> to that secondary web application once authentication is good.
>
> What is confusing to me is the SSLv2 request and then the TLSv1 response.
>
> From the point of sequest 631 and 651 ... between those two are just some
> LLC checks... no TCP.
>
> Yes, the 10.128.2.38 is the internal ADAM instance.
>
> What's throwing me, and what I don't understand, is the 3 ports opened to
> ADAM from the web server. Is this a result of the TCP DUP?
>
> Ted
>
> "Lee Flight" wrote:
>
>> Hi
>>
>> so looking at the problem trace you pick up (20.04s,19.93s,19.93s,19.75s)
>> so say 20s at each of the 4 points below. It also looks from your trace
>> sequence numbers (the first number on each line?) that there are ~128
>> packets not shown during each of those intervals what was happening
>> there?
>> Noted also that the problem trace has 4 Client Hellos whereas "normal"
>> trace
>> has 3.
>>
>> Also your traces from the WWW server in both cases only show packets
>> with 10.128.2.38 (the intranet ADAM instance?) as destination.
>>
>> Thanks
>> Lee Flight
>>
>> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
>> news:A7E4EE55-7641-4500-AF4E-A7E52C023ECB@microsoft.com...
>>
>> > "506","52.862277","172.16.0.36","10.128.2.38","TCP", "cognex-insight >
>> > ldaps
>> > [ACK] Seq=40 Ack=4997 Win=65535 Len=0"
>> > "634","72.906563","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
>> > Client
>> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>>
>> > "651","72.934195","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps
>> > [ACK]
>> > Seq=40 Ack=4997 Win=65535 Len=0"
>> > "785","92.859324","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
>> > Client
>> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>>
>>
>> > "869","92.914686","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps
>> > [ACK]
>> > Seq=40 Ack=4997 Win=65535 Len=0"
>> > "997","112.843447","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
>> > Client
>> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>>
>> > "1028","113.122915","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps
>> > [ACK]
>> > Seq=1816 Ack=65639 Win=64742 Len=0"
>> > "1157","132.874402","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
>> > Client
>> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
>>
>>
>>
Re: ADAM handshaking very slow in a DMZ [message #159842 is a reply to message #159839] Mon, 10 August 2009 07:45 Go to previous message
Ted Wagner  is currently offline Ted Wagner
Messages: 13
Registered: August 2009
Junior Member
That makes a lot of sense. This is similar to what I see in SharePoint myself.

The forms authentication control is just the standard control provided in
Visual Studio; so it's just a canned form auth. The developer pretty much
just took the TechNet examples and made changes appropriate for our
environment.

What confuses me though... and this is what is odd; even if I reset IIS and
the appPool on the internal test of this guy that delay is far shorter
internally. Typically I would expect the delay to be identical. Which is
what I see with SharePoint used both as an extranet and intranet application.

Although, you've given me something to think about that could be totally
indendent of ADAM and that would be ASP.Net and the control added in Visual
Studio.

Ted

"Lee Flight" wrote:

> Hi
>
> as to the 3 ports or perhaps the 3 client hellos then that does not surprise
> me so much as it will depend on how the application is written so it's
> common
> to have an application that uses a reader account to match a user in the
> directory
> and return say the distinguishedName of the user and then have the
> application
> re-bind using that distinguishedName and the user supplied password to
> authenticate
> the user. Hard to say without access to the application source.
>
> However I'm now wondering that as your application does nothing on the wire
> during those 20sec delays what the application is doing and perhaps the SQL
> instance is the clue... something I have seen with Microsoft Sharepoint is
> that
> the first user of an intranet Sharepoint during a working day gets a delayed
> response
> and that subsequent responses are slicker until the next morning - the cause
> in that
> case was that the application connection to the backend database (SQL) idles
> out and when the connection is re-established for the first user there is an
> overhead/delay in setting up the DB connection...not sure if that would fit
> with your application architecture?
>
> Lee Flight
>
> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> news:888E5BAF-3EE8-4EAE-8AC3-0F26A020DD52@microsoft.com...
> > The missing packets are LLC checks and other unrelated packets. Those all
> > appear to be normal. I just didn't want to clutter the post with those.
> >
> > There's a second web application (on the same box) which queries SQL and
> > returns data to the user. This forms authentication piece just directs
> > them
> > to that secondary web application once authentication is good.
> >
> > What is confusing to me is the SSLv2 request and then the TLSv1 response.
> >
> > From the point of sequest 631 and 651 ... between those two are just some
> > LLC checks... no TCP.
> >
> > Yes, the 10.128.2.38 is the internal ADAM instance.
> >
> > What's throwing me, and what I don't understand, is the 3 ports opened to
> > ADAM from the web server. Is this a result of the TCP DUP?
> >
> > Ted
> >
> > "Lee Flight" wrote:
> >
> >> Hi
> >>
> >> so looking at the problem trace you pick up (20.04s,19.93s,19.93s,19.75s)
> >> so say 20s at each of the 4 points below. It also looks from your trace
> >> sequence numbers (the first number on each line?) that there are ~128
> >> packets not shown during each of those intervals what was happening
> >> there?
> >> Noted also that the problem trace has 4 Client Hellos whereas "normal"
> >> trace
> >> has 3.
> >>
> >> Also your traces from the WWW server in both cases only show packets
> >> with 10.128.2.38 (the intranet ADAM instance?) as destination.
> >>
> >> Thanks
> >> Lee Flight
> >>
> >> "Ted Wagner" <TedWagner@discussions.microsoft.com> wrote in message
> >> news:A7E4EE55-7641-4500-AF4E-A7E52C023ECB@microsoft.com...
> >>
> >> > "506","52.862277","172.16.0.36","10.128.2.38","TCP", "cognex-insight >
> >> > ldaps
> >> > [ACK] Seq=40 Ack=4997 Win=65535 Len=0"
> >> > "634","72.906563","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> >> > Client
> >> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
> >>
> >> > "651","72.934195","172.16.0.36","10.128.2.38","TCP", "cardax > ldaps
> >> > [ACK]
> >> > Seq=40 Ack=4997 Win=65535 Len=0"
> >> > "785","92.859324","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> >> > Client
> >> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
> >>
> >>
> >> > "869","92.914686","172.16.0.36","10.128.2.38","TCP", "rdrmshc > ldaps
> >> > [ACK]
> >> > Seq=40 Ack=4997 Win=65535 Len=0"
> >> > "997","112.843447","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> >> > Client
> >> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
> >>
> >> > "1028","113.122915","172.16.0.36","10.128.2.38","TCP ","cardax > ldaps
> >> > [ACK]
> >> > Seq=1816 Ack=65639 Win=64742 Len=0"
> >> > "1157","132.874402","172.16.0.36","10.128.2.38","TLSv1 ","Certificate,
> >> > Client
> >> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message"
> >>
> >>
> >>
>
>
>
Previous Topic:Cannot change the user's password
Next Topic:ADUC won't open
Goto Forum:
  


Current Time: Thu Jan 18 20:51:52 MST 2018

Total time taken to generate the page: 0.15467 seconds
.:: Contact :: Home ::Sitemap::.

Powered by: FUDforum 3.0.0RC2.
Copyright ©2001-2009 FUDforum Bulletin Board Software