This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

LDAP authentication problems

0

hi guys,

I have pretty much the same issue. I have a SERVER (.129) authenticating to an LDAP SERVER (.53)

Sometimes works, sometimes it does not.

I am checking it, and:

SOURCE    DESTINATION         PROTOCOL         INFO

.129      .53                 TCP              ldaps [FIN, ACK] 

.53       .129                TLSv1            Encrypted alert
.129      .53                 TCP              ldaps [RST] 

.53       .129                TCP              ldaps [FIN, ACK] 

.129      .53                 TCP              ldaps [RST]

Any comment is very welcome :)

HINT: I converted your comment/answer to a question, as it’s better to handle your request in a new question, instead of the original question: http://ask.wireshark.org/questions/14212/router-replies-with-rst-after-fin-ack (Kurt)

asked 12 Jul ‘13, 01:49

dora's gravatar image

dora
11●1●1●3
accept rate: 0%

edited 12 Jul ‘13, 03:11

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237

One Answer:

1

.129 .53 TCP ldaps [FIN, ACK]

This is not necessarily a network (or IP stack) problem, as the LDAP client (server .129) actively closes the connection. So, to figure out what's going on, you need insight into the (clear text) communication.

So, here are some questions:

  1. Do you have access to the private key of the LDAP server, to decrypt the comminication?
  2. In the 'good' case, how many packets are being exchanged between the systems?
  3. In the 'bad' case, how many packets are being exchanged between the systems?
  4. What type of LDAP server is this (OpenLDAP, Active Directory, ...)?

Regards
Kurt

answered 12 Jul '13, 02:51

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

Hi Kurt,

Thanks for creating another post. I was waiting for an email from Wireshark.org advising of the new comment in the old thread (your comment, Kurt), but never came up (possibly because a new thread was created). I am new to here, but this forum looks pretty cool. I am getting really hooked to Whireshark :)

Anyhow:

  1. Waiting...
  2. Working on it...
  3. Working on it...
  4. Open LDAP

The thing is, that this was working ok when the servers were phisycal servers, but now they a Virtual machines (Vmware), since then, they face this issue.

(17 Jul '13, 05:23) dora

Here we have an example when LDAP authentification does not work. This is TCPDUMP running on 10.X.X.129, listening to port 636

alt text

(17 Jul '13, 06:48) dora
1

BTW: if you want to skip the encryption (because you can't get the keys easy) and want to capture the traffic visible to you without the keys you can use DavMail:

http://davmail.sourceforge.net/index.html

It's an open source gateway for services like POP/IMAP/SMTP/Caldav/Carddav/LDAP.

The client/server communication will still be encrypted but you will capture the unencrypted traffic locally:

10.X.X.129 ---unencrypted traffic ---> 10.X.X.129:1636 ---encrypted traffic---> 10.X.X.53:636

tcpdump on port 1636 will give you some hints.

(17 Jul '13, 11:09) Edmond

what is the sort order of the packets in your screenshot?

(17 Jul '13, 15:41) Kurt Knochner ♦

Edmond, Thank you. Will check out ASAP.

Kurt, Thank you. I just ran TCPDUMP on port 636 in the Server (client), no in the LDAP Server. Then I tried to authenticate, and it failed (it failed at the first attempt, therefore I stopped TCPDUMP)). This is all I got. Just few packets.

(17 Jul '13, 23:37) dora

BTW, I believe, that the failing Servers (clients), since they are Vmware machines, are adding some wrong info to the TCP handshake. It is pretty weird, cause after not using the server for some time (hours), sometimes it works at the first attempt, and sometimes it does not. Like TCP FIN timeout is not steady.

(17 Jul '13, 23:41) dora

@dora Your "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information.

(18 Jul '13, 01:06) grahamb ♦

@dora: some suggestions:

  • How do you authenticate against the LDAP server? Is that something built into an application? Until you get the server key, can you check the logs of the application for any errors?

  • How did you virtualize the systems?

  • How is the networking for the virtual systems configured (e.g. bridged interfaces, NAT, etc.)?
  • Is it possible to post the whole communication as a pcap file somewhere (Google Drive, dropbox, etc.)? We would need a capture file for the "good" case and for the "bad" case.
(18 Jul '13, 04:57) Kurt Knochner ♦
showing 5 of 8 show 3 more comments