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

SASL GSS-API Privacy

0

Hi,

Just wonder if it is possible to decrypt the signed LDAP packets to and from a Windows server. I have disabled LDAP signing on the client and server, plus implemented various registry settings that are also meant to disable this however after binding the next packets are all listed as SASL GSS-API Privacy. The changes have allowed me to see the bind request and response however the next packets are a mystery.

I'm trying to see the information returned when using Outlook 2007 and the autodiscover process internally (i.e. domain machine on the domain). Supposedly Outlook should query AD for a list of SCP objects and return these and I suspect this information is contain in these signed packets.

The client is Windows XP SP3 and the server is Windows 2003 R2.

Anyhelp would be appreciated.

Kind regards.

asked 01 May '12, 04:24

ElasticSky's gravatar image

ElasticSky
6113
accept rate: 0%


One Answer:

0

GSSS-API decryption should work with the KRB5 decryption of wireshark.

You'll need to change to protocol preference for KRB5 ("Try to decrypt Kerberos blobs") and you'll need a proper keytab file.

http://wiki.wireshark.org/Kerberos

Did you try that?

Regards
Kurt

answered 01 May '12, 11:51

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hi Kurt,

Thanks for reply - feel like such a noob. Changing the protocol preference for KRB5 did the trick (with a correct keytab of course).

Thanks for the excellent repy, it is very much appreciated.

Kind regards.

(01 May '12, 17:22) ElasticSky

Just wondering if you are able to help again :)

This worked in my lab but when I went to production fails and again I cannot decrypt the packets. The command I'm running to create the keytab file is:

ktpass /princ [email protected] /pass user-password /crypto RC4-HMAC-NT /ptype KRB5NTPRINCIPAL /out file.name

NB: ptype does have underscores but the editor ignores them.

I'm assuming the keytab is wrong which is why I cannot decode the packets however this might be a wrong assumption.

Thanks in advance.

(01 May '12, 20:13) ElasticSky

1.) just by chance: did you mix up the different keytab files?

2.) You did not specify the /mapuser param. Is there any reason for that?

3.) Is there any larger difference between your lab and your production domain?

4.) Can you please try to use ktexport instead of ktpass (it's also in the wiki)?

Regards
Kurt

(01 May '12, 21:15) Kurt Knochner ♦

Hi Kurt,

Answers as follows: 1) Created a new keytab file using the same command as above as this a different domain and user

2) Didn't think it was required as not mapping a service/account to a user

3) LAB is using 2003R2 DC's whereas PROD is 2008 R2**

4) Running ktexport crashes the lsass.exe service on the DC when run

** After trying again in the LAB but with a different user I'm again unable to decrypt the packets. This is on the same client but with a different account. Therefore thinking it cannot be the OS version of the DC's.

Thanks.

(01 May '12, 21:39) ElasticSky

Okay - if I change the "LDAP Client signing requirements" from "Negotiate Signing" to "None" then I can decrypt the packets assuming they are captured while this is set to "None"

This seems to change the LDAP encryption from SPNEGO - Simple Protected Negotiation to NTLM SSP. This can be decrypted using the keytab from a domain user account. The SPNEGO however can not - not sure what I need to the get the keytab file from if that is possible.

Unfortunately disabling LDAP signing on a WinXP client connecting to a W2K8R2 DC doesn't seem to work as the client continues to use SPNEGO.

Thoughts?

(02 May '12, 03:21) ElasticSky

-- Thoughts?

I'm trying to understand the problem....

(02 May '12, 04:38) Kurt Knochner ♦

Okay - I hope this helps: What keytab file would I need to generate in order to decrypt packets using Simple Protected Negotiation authentication?

With a WinXP client connecting to a 2008R2 DC it does not appear to negotiate down to NTLM authentication and therefore I cannot decrypt the packets using the user account keytab.

(02 May '12, 22:07) ElasticSky
showing 5 of 7 show 2 more comments