Closed Bug 743909 Opened 12 years ago Closed 12 years ago

GSSAPI not working for IMAP

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Version:
12 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: adrien, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.151 Safari/535.19

Steps to reproduce:

Enabled Kerberos/GSSAPI

***Server is on same computer as client*** don't know if this is significant, since kerberos is out-of-band

***Server is our own product*** we just added support for GSSAPI, and I was testing it.

We may have messed up somehow but I'd expect something to be sent by the client?  Or did we not register our server with kerberos properly?  I note in RFC 1731 the client is supposed to initialise kerberos with some token like SERVICE:imap@hostname, does that presume the server is also supposed to register some similar endpoint?  


Actual results:

TB connects to the IMAP server, and immediately disconnects posting a message saying the ticket was not accepted by the server.  No protocol was sent by TB to the IMAP server.

TB imap log:

7224[ddf0700]: b09c000:localhost:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE WITHIN CONDSTORE IDLE ESEARCH COMPRESS=DEFLATE AUTH=GSSAPI LOGINDISABLED] WinGate IMAP4rev1 service ready

7224[ddf0700]: try to log in
7224[ddf0700]: IMAP auth: server caps 0x57086431, pref 0x1000000, failed 0x0, avail caps 0x1000000
7224[ddf0700]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN =  0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)auth external IMAP login = 0x20000000
7224[ddf0700]: trying auth method 0x1000000
7224[ddf0700]: IMAP: trying auth method 0x1000000
7224[ddf0700]: MD5 auth
7224[ddf0700]: authlogin failed

I wonder about the line saying "MD5 auth".

Server log protocol level is just

10/04/2012 15:57:16.078	New connection: 
10/04/2012 15:57:16.078	<=S: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE WITHIN CONDSTORE IDLE ESEARCH COMPRESS=DEFLATE AUTH=GSSAPI LOGINDISABLED] WinGate IMAP4rev1 service ready
10/04/2012 15:57:16.158	Session terminated: client disconnected

TIA
Adrien


Expected results:

I was hoping it would work.
I managed to get some more logs out of the auth system. 

5124[e2ef700]:   nsAuthSSPI::Init
5124[e2ef700]:   InitSSPI
5124[e2ef700]: Using SPN of [imap/BOMBED.qbik.local]
5124[e2ef700]: AcquireCredentialsHandle() succeeded.
5124[e2ef700]: entering nsAuthSSPI::GetNextToken()
5124[e2ef700]: InitializeSecurityContext failed [rc=-2146893053:]
5492[e2f09c0]:   nsAuthSSPI::Init
5492[e2f09c0]: Using SPN of [imap/BOMBED.qbik.local]
5492[e2f09c0]: AcquireCredentialsHandle() succeeded.
5492[e2f09c0]: entering nsAuthSSPI::GetNextToken()
5492[e2f09c0]: InitializeSecurityContext failed [rc=-2146893053:]

-2146893053 is 80090303, which implies the SPN wasn't found.

I checked the SPN, and it's registered for the account the service is running in.  I've tried all sorts of variations, including with the port number.
(In reply to Adrien de Croy from comment #1)
See bug 303160.
Nikolay can you help here ?
Can you give us more details? This is windows 7 machine joined domain? Who responosible for Kerberos Realm, windows AD, which version?
Hi

client is win7 x64 joined to domain, account I'm working in is also a domain admin account.  AD server is (embarrasingly) win2k SP4.  Realm is under our control.

SPN is registered against the object for the computer the IMAP service is running on 

I don't fully understand how the SPN is found by the client, since it lives inside an AD object relating to a computer account (rather than in some obvious to find place).

thanks!

Adrien
Adrien, spn stored in LDAP you can easily find it using any ldap utility. But most cases it may enough to use setspn.exe utilty. So if your server name BOMBED.qbik.local use such command "setspn.exe -L BOMBED.qbik.local" to check whatever spn availble for OS or not. You can actually use setspn, to create new one. Be aware that service name in SPN are case sensetive, "imap" must be lower case.
How you actually make registartion?
Hi

I was using setspn.exe, and verifying with that and also with an LDAP browser.

I presume the reason that the attribute goes against a user/computer object is to set up crypto so the ticket can be created to be readable in the context of the server, but we're not getting that far.

I also tried case sensitive, exactly as was logged in the TB SSPI debug log.

imap/BOMBED.qbik.local

MS docs are confusing on it, they seem to indicate you need a server instance and SRV record, I even created those (several SPN attributes) but nothing seemed to help.

It's not necessary to reboot the AD server is it?  I rebooted the client each time just in case.

thanks

Adrien
OK, made some progress (not exactly sure what).

I added another SPN just imap/BOMBED and now the server logs show me this:

New connection: 
<=S: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE WITHIN CONDSTORE IDLE ESEARCH COMPRESS=DEFLATE AUTH=NTLM AUTH=GSSAPI LOGINDISABLED] WinGate IMAP4rev1 service ready
C=>: 1 authenticate GSSAPI
<=S: +
C=>: YIIErwYJKoZIhvcSAQICAQBuggSeMIIEmqADAgEFoQMCAQ6iBwMFACAAAACjggPHYYIDwzCCA7+gAwIBBaEMGwpRQklLLkxPQ0FMohQwEqADAgEBoQswCRsHQk9NQkVEJKOCA5IwggOOoAMCAReiggOFBIIDgR3CLd3M0eDdy3fTesHVDHbOtcfXm2ssUUjo8iDSOu/gFBgOaOgw0EMIm9czf9LsVEVavFfpuE86andqgYRGaPvzFu521bCa9Yt1akjiqJLl8uIEOw8WN0dV34ZhSzyswGOgM90e82UrJLMfw7bajvb7G/pFscWWxHXVH7RcjMdLAxH5JbJ989GkuJZxYnbgHOfgEcoVxP9HYxGTFn65N4Zd82T7PRWEmFithrqV7FNnfcvaY7k7eQdkW+69u7ebCXldH2rFac8KY1euKwdBgA/zGNEEJjVrrbtpWs6r3F9ey1ws64/3Ps3bYCltsagjAAdHBFWxp4Sy9eOZRPMr8LmMXmiud7I9y4NhWRpHDXmPsS7alqlE9snos0BVhMSqckV+5hzOBxDkas763XPCbfmJeO8dVCwnOwDjpZqOq5qdBXXGzefoSNc2YlBbCIVTNk4ESYesZQKAjdwGP9N/KXe7jfy/ecWQngViGOdj/CLhrXA4jKXEZWl1SI4cDles7O+ZJ4sJwLRRZARZdl2gysbMlj2sovgrgdHG6cgVfKsPgpb6GlzptIvulWV981ALhhXe60oarmWodGdF+m5kiq3yTQHlLCHA72tgpKZpWpiJglGqGgfvwyt3Xl7TD97kqz5xGUDD4TM4P8m179aHDWlR3uo9pjlz8PZW3xQek5PArVzN5U5P/sGk3+oNrtWOat2Jz92CZ/Bu0XnleYjvKiNpWI6SK+5i3PmqHhRW9WNXF+CZM6zs/IRFMgYpzusCaUNw8aH99qurRY0wCmdWueiC4BRJHm/FOp+4xxCQIjWfCt6wqeNGZvIKrpMv2ln7O6qGGklFODEdZrYFTuc4PS5kq3KCxdJzwiVyEuwhf7gS+GDwNzR079HutdlDVpDLyaACQgz5KyRjkzBPlimNHLHSuKolVitpBi1mw6nsTfwvS0d01MQM7DUcp8i8dCZhLrQeQhG31Jpt7s5p2SfacMykqEVblSrT4qVia1zvRMvne85Lz/qh3k/VdxX8ovCYKLeyfoOJOSS2fYupNXljGki+mG51BErl65DtNvcbkEQQkvS3fUJr/ZCUbIgdJaySNN1a73hiuvtLcC2arbTZQIU4YwfKyQ5nwO9wlpcOKbo1e1yfSatYJ3O9TS1xNf1JkRQIj7Nh5vefS6CZKMufE4XbvGQXzoFdahjRxlfe3z6JFKSBuTCBtqADAgEXooGuBIGraJNsb53b/NQHCAi7BDci+lxz5NtCEudobmHoWTUjwcg2dGf286tP5W92IcuhrsQXR8uvQK0qF/5UL8v87FJ402Cqu8LVbNf1uW18FnO+VDL1nwY1LqIB2pvoSV9Tsy7oKtGLdf29sGznGkCIqXsbkFLSlO++Q+Rn7GsYaekJ67YBemKdOXU/m3MVd8xWoJ4tMD/acO0IKhJW/sNSWlL25Aw02JIi/8KAMYFI
==== GSSAPI AUTH succeeded - user (Adrien W. de Croy) authenticated
<=S: 1 OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE WITHIN CONDSTORE IDLE ESEARCH COMPRESS=DEFLATE AUTH=NTLM AUTH=GSSAPI LOGINDISABLED] AUTHENTICATE Adrien W. de Croy authenticated
C=>: *
<=S:  NO command invalid in this state

TB still complains about the ticket being rejected.  Maybe something to do with the CAPABILITY advertisement?

* is normally a means to cancel SASL auth, but it's already completed.

I'll take another look in the TB source to see why it would send a *.

thanks

Adrien
OK, I know what the problem is there too... server not sending remaining data back to client when auth succeeded.

I'm picking this will be a no-op for you guys

thanks heaps for the help
Nikolay : Thank you very much !
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
actually maybe I spoke too soon.

Client is sending a successful ticket, server sends response back, client then sends an empty line, to which our server sends the final OK response.  Then the client cancels.  I think it thinks it's still in the loop for auth or something and tries to send the 1 OK AUTHENTICATE succeeded to the SSPI or something.  

here's the IMAP and SSPI log


2952[4de4400]: 582c000:bombed:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE WITHIN CONDSTORE IDLE ESEARCH COMPRESS=DEFLATE AUTH=NTLM AUTH=GSSAPI LOGINDISABLED] WinGate IMAP4rev1 service ready

2952[4de4400]: try to log in
2952[4de4400]: IMAP auth: server caps 0x57186431, pref 0x1000000, failed 0x0, avail caps 0x1000000
2952[4de4400]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN =  0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)auth external IMAP login = 0x20000000
2952[4de4400]: trying auth method 0x1000000
2952[4de4400]: IMAP: trying auth method 0x1000000
2952[4de4400]: MD5 auth
2952[4de4400]:   nsAuthSSPI::Init
2952[4de4400]:   InitSSPI
2952[4de4400]: Using SPN of [imap/bombed.qbik.local]
2952[4de4400]: AcquireCredentialsHandle() succeeded.
2952[4de4400]: entering nsAuthSSPI::GetNextToken()
2952[4de4400]: InitializeSecurityContext: continue.
2952[4de4400]: 582c000:bombed:NA:SendData: 1 authenticate GSSAPI

2952[4de4400]: ReadNextLine [stream=582e848 nb=4 needmore=0]
2952[4de4400]: 582c000:bombed:NA:CreateNewLineFromSocket: + 

2952[4de4400]: 582c000:bombed:NA:SendData: YIIErwYJKoZIhvcSAQICAQBuggSeMIIEmqADAgEFoQMCAQ6iBwMFACAAAACjggPHYYIDwzCCA7+gAwIBBaEMGwpRQklLLkxPQ0FMohQwEqADAgEBoQswCRsHQk9NQkVEJKOCA5IwggOOoAMCAReiggOFBIIDgZFHHovH2CKPpmJPgOAeXo9V+4iYwMoFQfFXoIyY66MbxY4t9RY+wJqwFee/BXPWfnRm9LsQxcj0FHsM/k81ZNEGHgfyvQglhr3JTDnH6oO4ebbzS/whSCtMNbgqDAe8OV+Sw/6QhH9ZGcFlvZ+h0AjpDS4kcA5r9HlesklUNb4zZfAXzwxLHbTBqHsr5jYqdpqki6DLu6eMDGLTabJqud/GZwxJtuNI7IcqUEfDWl1Li1vj4r4b
2952[4de4400]: ats8Jt1nKn7wYAekaoYRj07lJXaZBkyqDTsXw8tHDa9bp890owWlkmydJia2cV+BQ2qiVaadCnqVb1JptVEIVMaW48P3qpyoh6XNPDSv+0qoWtzuLDUDv3hhYliaLwp8M1zoR5c57bWzA3F24ETA5sGQxCdcce9y3K5AVIQSQJJPVP1y+aLmnjJTrgPej6ZmKVUNp2frrs41X88r6J56Kk4v7KoBFK6pflMj2mV1y1eVRxXoGaaQTHUnsZhRtyxKRtxMQdMYjRubFicpzjSmYsxQWKC3JMO0J6qzSoIUaYWLE9du7zBUAcLQLD9kFwK5idlZeUCTBxJd+lWNBtD0C8Dn2va+04B1D8tEF8Txx+7bdz23WNNaBlWFU5CpE8g7eGM+lJ94sf5r9GWG
2952[4de4400]: 1UBXDMmuxSm3D1CMu//ioTP2En9qwztztqkXHZX+ntLqvRe5kvS609isTRhKcN7svC7T3sqesSUrt+ik++IKNVYC4rt7XG8MlPMmwRmWcPeHjW8VjK/RsSNKlAdrWmyHKDxcA1GLs2anFXJ2Vbrulk8U+ZbPjwlNyh6FVECBd7PK0ncTyfyp7qjXF3c8UMXhcOmRwh3cTK2iXs3hlWOij8yWYJ+um0/ucepGsbUPr6j4kwkrHarLOvef46/9unP0Dm15n3q7SNGXa1TEv7VDSKcOAnNkPV3tngPKOjO+fB+fQRmJQIv45mYo7/2r8Sow/IlCMFi/O63J8oizGUAIgpHmErPSNO86WFJp4p+R82UULyi2as/otPBi3RKemKZL2sYSifoufmp+5/no
2952[4de4400]: 2njtr6lODhplX2SUUboo0T560K42ByUnpxWR3FxMdilKqkLAqgro8w3bAhcgxUUmy3L6Gxw1hyCukuzKoeEgbWOXUMoiFiXFxA8jv2L5ltIifr1/CppzwO5i2R99DYFRa/DiyJ24JkHJWw2DQvq/6un0t6SBuTCBtqADAgEXooGuBIGr/6DcTiuRyjbOcP3OiW8JnaC2Bpx4QM+E+zLhCDITedJtAoHxGjkn8d0LaXWZ4pz+FPayZ/rzdUALL4xiRbIScSM7xA6Rbk8p3hVAeNTqmfHAkKN/i/MbeWWm8Iaqo2H33MxjuhnUTaWGOgyJamYKk/7K5vXQeZ0o9q5pjlVfja1N23+VQIddkOkgyX81CW/uYmVEQj5JHS6ba/ZokbYv4ufnZuoCgCSc
2952[4de4400]: M2NR

2952[4de4400]: ReadNextLine [stream=582e848 nb=184 needmore=0]
2952[4de4400]: 582c000:bombed:NA:CreateNewLineFromSocket: + YIGCBgkqhkiG9xIBAgICAG9zMHGgAwIBBaEDAgEPomUwY6ADAgEXolwEWpYh+/QzLKfzQXfx3jBhlYp+IHNi6d1+EHCSMo6CTf3mVRseme2V6lGvugsoublQdOSVzAtcOMG/kUCNo1BI8rCxctB2s1e8uZkjkksJKHVBYquzVXHAylYTFQ==

2952[4de4400]: entering nsAuthSSPI::GetNextToken()
2952[4de4400]: InitializeSecurityContext: succeeded.
2952[4de4400]: 582c000:bombed:NA:SendData: 

2952[4de4400]: ReadNextLine [stream=582e848 nb=51 needmore=0]
2952[4de4400]: 582c000:bombed:NA:CreateNewLineFromSocket: 1 OK AUTHENTICATE Adrien W. de Croy authenticated

2952[4de4400]: 582c000:bombed:A:SendData: *

2952[4de4400]: ReadNextLine [stream=582e848 nb=35 needmore=0]
2952[4de4400]: 582c000:bombed:A:CreateNewLineFromSocket:  NO command invalid in this state

2952[4de4400]: authlogin failed
2952[4de4400]: marking auth method 0x1000000 failed
2952[4de4400]: IMAP auth: server caps 0x57186431, pref 0x1000000, failed 0x1000000, avail caps 0x0
2952[4de4400]: (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN =  0x200000, PLAIN = 0x1000, LOGIN = 0x2, old-style IMAP login = 0x4)auth external IMAP login = 0x20000000
2952[4de4400]: no remaining auth method
2952[4de4400]: login failed entirely
2952[4de4400]: 582c000:bombed:NA:ProcessCurrentURL: aborting queued urls
2952[4de4400]: 582c000:bombed:NA:TellThreadToDie: close socket connection
2952[4de4400]: ImapThreadMainLoop leaving [this=582c000]
3096[4de6480]: ReadNextLine [stream=5c06748 nb=0 needmore=1]
3096[4de6480]: 58c0000:sago:NA:CreateNewLineFromSocket: clearing IMAP_CONNECTION_IS_OPEN - rv = 804b001e
3096[4de6480]: 58c0000:sago:NA:TellThreadToDie: close socket connection
3096[4de6480]: 58c0000:sago:NA:CreateNewLineFromSocket: (null)
3096[4de6480]: 58c0000:sago:NA:ProcessCurrentURL: aborting queued urls
3096[4de6480]: ImapThreadMainLoop leaving [this=58c0000]

and server protocol log:

New connection: 
<=S: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR UNSELECT LITERAL+ ID UIDPLUS ENABLE MOVE WITHIN CONDSTORE IDLE ESEARCH COMPRESS=DEFLATE AUTH=NTLM AUTH=GSSAPI LOGINDISABLED] WinGate IMAP4rev1 service ready
C=>: 1 authenticate GSSAPI
<=S: +
C=>: YIIFugYJKoZIhvcSAQICAQBuggWpMIIFpaADAgEFoQMCAQ6iBwMFACAAAACjggQxYYIELTCCBCmgAwIBBaEMGwpRQklLLkxPQ0FMohQwEqADAgEBoQswCRsHQk9NQkVEJKOCA/wwggP4oAMCAReiggPvBIID62+33ntPpDSAYNT8MoZ3d0aLeF3yAySwuHnzpVw90tP/dNvWYpa0/IfIh7febYZ+y02QECYC+lbIRrExdLv1Em/pclAqZvOj/6PN/2PW5BYWQRVPT4MpIEUtfrd7PRtAhcA3yAZiFqo5NZDFuywBCqvePb/QidQwVryui5VNdn5+SrTNy+ZaCIYVE3TDjQRTvTyxF3z+Tf8MuE7avSRYfv57haAeNtQRgSUZhUUm4T4nqQdY+2jOl8E23MnEy4aJZGrX3lQmStvb3LnHjf1Ao2eSR87ehrSvgfMQpJwWjHvb4tsCkptxD/hPHG45RIx56/EP5oxD9Zmoj2P4WgAMOtge/mikxXimskZXWnREODvfAskW3/vw39PCXw/2RyJl8z8/iap5qSRuPaJQejgkI6EXFW851+gV1B4mf5m9lKrEyNJVLNfMN7N1B3dWdLA/RrCiHqCfcmqP9pqMhjtEFaINMnwCg9rhwhqio65b78t9UAFGOfu8HshzWM0LqYqtXxKzYtzrs3hXETt+c0ZxHlSs2Ihw6M92Hs/YnzNsPQrzbM4oJiaCakRVZA9We7d8NTYSYtOb+Jr82ydJ4m0hAOS/HeWhIYsyfs7l+68BiJQHsiwySBi5U6vonUlLidbWDEgHRMMR31tJ7TUfIlp9eeur+NWbrb66G817IwqWiIECRbFYi50HRgkuZMdoIqItXd2Ena2jxrx0NTjDFJ0QjHKKqJHqShQlOA2ZY4jlsVA0KmcDioS/jeHaQajkxVLpKbYJEPIkLpX6GcWrJVxv/nq/etZE//e1Zanf9L2HYaxMQGomYXzZhuwQ9QtIs6RqGQO4IOnR4XpofO8jqd079h6LWvzPKI7Q4fGS+at/b7RYNGqn2QrSfl9lbtmaRUMSbFaRqJL4n19EPAGSvVBQQmI91x9z5on9Jwf3H22/ggKn1+mjlHC5Z/K//9OyTaybh93q30LYc33xulWeOBerwmrMhLJ/6s72PEOYQukxg9tXfs86iwxLNxUPfcmYwhLxaPyClbxtP3xVYiN/3Pc9aE1MNmKEl+BX9tj+3s/bfPMckbaOWsgXu6WC4YDXBaII4HRdGdslyUENsUEdnSvYj8qlIe0wql85SZtHOD6aHoMQlrfwxBVv6rkfidhTUjqL8dI7BGO28teBDjX4QghTFsmPw3lTC+wGawU1vmg/6IZVrJTkdHbdreOvIGvdatGwv9ULlcCQMK8ZxMasVF/2N63+2ubTY9RHPo9UniqowEFhcWCf15eW/uU+QA+4PzaF+HGx5dDrTbm2LiKdfKw2pFrxWwtVR6Qc8rWLqMa63hSGRC/OwaCpomqtPkGkggFZMIIBVaADAgEXooIBTASCAUhWjTOX43K9wILfVCAc418LMSf8LRTHMV47hSnDz4c4+aCL1m0uKBddKricOuDff/J851c0CYvQ0tN+hwhHqUcYDHgUNAORbcGFAl8E13iHT9dQNZUUBOUNHDK0SNjsYElMpWGZsGhigE4b1GXBkn2rkmt4kiTX9l8bo0EJs3lW+xLdB+8eYiOqSBwttGmLE4lgTLI6TDOb69rfJIv1FpMm04/xOih1N3YwrQo8oMcolBXnwOVP/Th6UKY8gnDpEl29nMfmp+2fT5VohQjRN8FG6djMXAXCx4CvbqHSIZqVMTIlJ8EqFDVFj3A5xL1s00e0vt2OB0jdFPkoJTnZ61VHrVPGoRJ/8UV86cvu3fzywyww1aD34ZrAP0Sf063zV2gjdYTUxHkPcvTA3iBK/cqAf7ExzzPc6MusJs4Mp92reRUe82zYmM+Z
==== GSSAPI AUTH succeeded - user (Adrien W. de Croy) authenticated
==== auth continuation required
<=S: + YIGUBgkqhkiG9xIBAgICAG+BhDCBgaADAgEFoQMCAQ+idTBzoAMCAReibARq+KOgI6Aid1nRPfyo8xuY/o8zJ4zI0RR3MjRamVACKyFksxJW9qnXeHYCvySOgJjAgjUO1al1z4wO6RFUdmbw4WcHso1BtqioAHdvJzWGRmlbe2+2N6QK84qAMUEGoMzjbbBw1I3vBBX7YQ==
C=>: 
==== GSSAPI AUTH succeeded - user (Adrien W. de Croy) authenticated
<=S: 1 OK AUTHENTICATE Adrien W. de Croy authenticated
C=>: *
<=S:  NO command invalid in this state
Traffic: 497  1990  0  0  0s
Session terminated: client disconnected

I'm wondering why the empty response to the final token, or is that to prompt the server to complete... 

what does a normal exchange look like?  I see in the code there are comments about Cyrus hacks for 0 length buffers.

Adrien
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
The protocol doesn't need to be wrapped after GSSAPI auth does it?

I see the 2 wrap / unwrap funcs, but I couldn't see anywhere in the TB source where they were actually called.
Well I don't know GSSAPI internals but, after empty line request, there should be response from server and then final request from client to finish authetication.
Hi

do you mean:

C: tag AUTHENTICATE GSSAPI CRLF
S: + CRLF
C: [ticket]CRLF
S: [continuation]CRLF
C: CRLF
S: CRLF
C: CRLF
S: tag OK...

?

Seems like a lot of empty round trips?
No, after empty request, server should reply with some binary data (I assume this is final key-exchange) and then client answer with some binary data to finish auth.
hi

by empty request you mean line 5 (c: CRLF)?

problem is when the client sends me the empty line, if I pass that into SSPI, I get an error 80090301 (invalid handle).

Our SOCKS server does a similar thing, and there's no 3rd exchange, just the c:ticket and the s:response, followed by c:empty followed by s:complete.

The SSPI had already completed I thought, so isn't expecting anything more.
Also Adrien I suggest you ask your question about development server in Kerberos mailling list, where you may get much faster answer about kerberos internals.
And what I suggested is what I'm seeing on my working TB installation on windows AD realm + unix imap server.
HI

thanks for your help.

One thing though AD <-> unix for kerberos does some things that just an AD client and AD server won't.  I don't know if that makes any difference.

I'll keep looking, thanks for your help.  If it comes back to point at TB, I'll let you know.
Thanks again Nikolay
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
Well real difference (or at least I'm aware of) is SSPI vs GSSAPI but you can disable SSPI and force gssapi on windows but you need MIT Kerberos client to make it work on windows.
Hi

Thanks again for your help.  According to RFC 4752 the subsequent transmissions actually are no longer SSPI.  They are post-negotiation of session confidentiality and mutual auth, which are binary packets which need to be wrapped and unwrapped.

So thanks for your help, and sorry I should have read the spec better!

Adrien
You need to log in before you can comment on or make changes to this bug.