Created attachment 3408 [details]
network capture trace

Here a network capture trace of negotiate

Another things that can help:

vzyinstall@vzy-p1197493:~$ ls
Desktop  toto  toto2
vzyinstall@vzy-p1197493:~$ klist
Ticket cache: FILE:/tmp/krb5cc_11108
Default principal: vzyinstall@TEST.ADS

Valid starting     Expires            Service principal
07/15/08 13:36:36  07/15/08 20:16:36  krbtgt/TEST.ADS@TEST.ADS
        renew until 07/22/08 13:36:36
07/15/08 13:36:36  07/15/08 20:16:36  VZY-P1197493$@TEST.ADS
        renew until 07/22/08 13:36:36


Kerberos 4 ticket cache: /tmp/tkt11108
klist: You have no tickets cached
vzyinstall@vzy-p1197493:~$ mount.cifs //sc01001/share ~/toto/ -o sec=krb5i,username=vzyinstall,password=fake
vzyinstall@vzy-p1197493:~$ mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755)
varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext2 (rw)
/dev/sda4 on /home type ext3 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
//sc01001/share on /home/vzyinstall/toto type cifs (rw,mand,nosuid,nodev,user=vzyinstall)
vzyinstall@vzy-p1197493:~$ umount.cifs ~/toto/
vzyinstall@vzy-p1197493:~$ mount.cifs //vzy-filertest/share ~/toto2/ -o sec=krb5i,username=vzyinstall,password=fake
mount error 5 = Input/output error
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)
vzyinstall@vzy-p1197493:~$

(In reply to comment #2)
> Another things that can help:
> [...]
> vzyinstall@vzy-p1197493:~$ mount.cifs //vzy-filertest/share ~/toto2/ -o
> sec=krb5i,username=vzyinstall,password=fake
Sorry, bad Copy/Paste.
Mount-point is //vzy-filertest/PartageCIFS, not //vzy-filertest/share

> vzyinstall@vzy-p1197493:~$ mount.cifs //vzy-filertest/share ~/toto2/ -o
> sec=krb5i,username=vzyinstall,password=fake
> mount error 5 = Input/output error

Looks like you hit this part of code in cifssmb.c:
»·······} else if (server->secMode & SECMODE_PW_ENCRYPT) {
»·······»·······rc = -EIO; /* no crypt key only if plain text pwd */
»·······»·······goto neg_err_exit;
»·······}

Because of according to server response it do not support extended security negotiation and kerberos branch fail in this part of code in cifssmb.c:661:
»·······} else if ((pSMBr->hdr.Flags2 & SMBFLG2_EXT_SEC)

So that is why it  doesn't work now.

However server says that it supports extended security in Capabilities field, so
I do not know who is correct here client or server.

There is more to why it may not work if we bypass this part of code:
Server supports MS_KRB5 OID type only from all other kerberos OIDs
and from quick glance in code it looks like that only KRB5 OID supported now.

This looks like a server bug to me. It seems like CAP_EXTENDED_SECURITY tells whether the server supports extended security, whereas SMBFLG2_EXT_SEC tells whether extended security is actually being used in the negotiation.

Also, AFAICT, we do handle MS_KRB5 via this piece of decode_negTokenInit():

                                        if (compare_oid(oid, oidlen,
                                                        MSKRB5_OID,
                                                        MSKRB5_OID_LEN))
                                                use_kerberos = true;


I could certainly be wrong on both points here, however.

I can sent you a network trace from a Windows XP Box which can "mount" the "PartageCIFS" share through Kerberos ?
If it was a server bug, the computer could not mount the share under Windows too ?
Or, can I "force" mount.cifs to do kerberos auth in this case ?

Thanks for your quick answers!

(In reply to comment #6)
> I can sent you a network trace from a Windows XP Box which can "mount" the
> "PartageCIFS" share through Kerberos ?
> If it was a server bug, the computer could not mount the share under Windows
> too ?
> Or, can I "force" mount.cifs to do kerberos auth in this case ?

It could use ntlmssp because of server declares it as one of supported auth types.
Look in Neg+Session Setup network dump between them and you will see what happens over there. (whireshark will help you to see it in rather friendly format)

(In reply to comment #5)
> This looks like a server bug to me. It seems like CAP_EXTENDED_SECURITY tells
> whether the server supports extended security, whereas SMBFLG2_EXT_SEC tells
> whether extended security is actually being used in the negotiation.
> 
> Also, AFAICT, we do handle MS_KRB5 via this piece of decode_negTokenInit():
> 
>                                         if (compare_oid(oid, oidlen,
>                                                         MSKRB5_OID,
>                                                         MSKRB5_OID_LEN))
>                                                 use_kerberos = true;
> 
> 
> I could certainly be wrong on both points here, however.

I not sure either if it works. In helper there is some shreds about MS_KRB5 but it not complete I guess.

As you can see in the capture next, the "Session Setup andX Request" is done by Kerberos (there is a "krb5_blob" in the trame #47 which is like a Kerberos ticket), but I not sure about that, anyone can confirm/afirm me ?

Created attachment 3409 [details]
network trace with kerberos

Thanks. The capture doesn't seem to be doing NTLMSSP...

It looks like windows just doesn't care that SMBFLG2_EXT_SEC isn't set. I suppose we could change all of the places in CIFSSMBNegotiate that check for it to just check for CAP_EXTENDED_SECURITY instead, but that seems broken to me.

Still, it's probably worth experimenting with a patch that does this to see if it will fix the problem...

Created attachment 3411 [details]
experimental patch

Here's an untested experimental patch. I think this would probably work around the problem, but it looks like it could also break non-kerberos mounts to servers that report CAP_EXTENDED_SECURITY. It seems like if we can't depend on the SMBFLG2_EXT_SEC flag, then we'll probably need to determine that we have a SPNEGO blob by checking some other criteria. Unfortunately, I'm not sure what that criteria should be right offhand.

Still, if this patch works, it should tell us whether our understanding of the problem is complete or whether there might be other factors at play as well...

Created attachment 3414 [details]
Network capture trace with patch applied

Okay, I have patch'ed the module, and insmod'ed it.
Now, the message is:
vzyinstall@vzy-p1197493:~$ mount.cifs //vzy-filertest/PartageCIFS ~/toto/ -o sec=krb5,username=vzyinstall,password=fake
mount error 22 = Invalid Argument

Dmesg output:
[92165.780757]  /home/vzyinstall/cifs/cifsfs.c: Devname: //vzy-filertest/PartageCIFS flags: 64
[92165.780768]  /home/vzyinstall/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 6 with uid: 0
[92165.780780]  /home/vzyinstall/cifs/connect.c: Username: vzyinstall
[92165.780785]  /home/vzyinstall/cifs/connect.c: UNC: \\vzy-filertest\PartageCIFS ip: 10.142.65.133
[92165.780794]  /home/vzyinstall/cifs/connect.c: Socket created
[92165.784258]  /home/vzyinstall/cifs/connect.c: sndbuf 16384 rcvbuf 87380 rcvtimeo 0x7fffffff
[92165.784289]  /home/vzyinstall/cifs/connect.c: Demultiplex PID: 15822
[92165.784299]  /home/vzyinstall/cifs/connect.c: Existing smb sess not found
[92165.784307]  /home/vzyinstall/cifs/cifssmb.c: secFlags 0x8
[92165.784309]  /home/vzyinstall/cifs/cifssmb.c: Kerberos only mechanism, enable extended security
[92165.784315]  /home/vzyinstall/cifs/transport.c: For smb_command 114
[92165.784318]  /home/vzyinstall/cifs/transport.c: Sending smb of length 69
[92165.796513]  /home/vzyinstall/cifs/connect.c: rfc1002 length 0xa1
[92165.796549]  /home/vzyinstall/cifs/cifssmb.c: Dialect: 2
[92165.796556]  /home/vzyinstall/cifs/asn1.c: OID len = 7 oid = 0x1 0x2 0x348 0xbb92
[92165.796566]  /home/vzyinstall/cifs/asn1.c: OID len = 10 oid = 0x1 0x3 0x6 0x1
[92165.796574]  /home/vzyinstall/cifs/asn1.c: Need to call asn1_octets_decode() function for vzy-filertest$@TEST.ADS
[92165.796596]  /home/vzyinstall/cifs/cifssmb.c: Signing disabled
[92165.796600]  /home/vzyinstall/cifs/cifssmb.c: negprot rc 0
[92165.796604]  /home/vzyinstall/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x8000d3fd TimeAdjust: 0
[92165.796608]  /home/vzyinstall/cifs/sess.c: sess setup type 6
[92165.796621]  /home/vzyinstall/cifs/cifs_spnego.c: key description = ver=0x1;host=vzy-filertest;ip4=10.142.65.133;sec=krb5;uid=0x2b64
[92165.808675] SPNEGO reply blob:: dump of 1196 bytes of data at 0xf754a810
[92165.808690]  58348d68 74bc1108 5209bb60 736b3e7f h . 4 X . . � t ` � . R . > k s
[92165.808699]  98048260 062b0606 02050501 8c0482a0 ` . . . . . + . . . . . � . . .
[92165.808708]  88048230 0b300da0 862a0906 12f78648 0 . . . � . 0 . . . * . H . � .
[92165.808716]  a2020201 04750482 60710482 066d0482 . . . � . . u . . . q ` . . m .
[92165.808725]  48862a09 0112f786 00010202 5c04826e . * . H . � . . . . . . n . . \
[92165.808734]  58048230 010203a0 0203a105 07a20e01 0 . . X � . . . . � . . . . � .
[92165.808750]  00000503 a3000000 61980382 30940382 . . . . . . . � . . . a . . . 0
[92165.808800]  a0900382 05010203 081b0aa1 54534554 . . . � . . . . � . . . T E S T
[92165.808808]  5344412e 1e3020a2 010203a0 3017a101 . A D S �   0 . � . . . . � . 0
[92165.808817]  68041b15 1b74736f 797a760d 6c69662d . . . h o s t . . v z y - f i l
[92165.808826]  65747265 82a37473 82305903 03a05503 e r t e s t � . . Y 0 . . U � .
[92165.808834]  a1170102 02010203 470382a2 43038204 . . . � . . . . � . . G . . . C
[92165.808902]  7a87c3d3 c0e6aff9 c15c5a40 29f5a5da � � . z � � � � @ Z \ � � � � )
[92165.808910]  84b1c8c1 f0a8dff7 8e4f6014 b413ba50 � � � . � � � � . ` O . P � . �
[92165.808918]  3d233e64 32c4ad7d e738a2bc 8fd8587b d > # = } � � 2 � � 8 � { X � .
[92165.808926]  f9827ce6 b79ee305 48b239ac 54e4eb50 � | . � . � . � � 9 � H P � � T
[92165.808934]  163de1d4 73763d83 483856d0 3e1e9dae � � = . . = v s � V 8 H � . . >
[92165.808942]  9a142e23 c5bd9aa3 1793cc1f abcde425 # . . . � . � � . � . . % � � �
[92165.808950]  710a3b11 48fb1d22 9939d834 308d15e2 . ; . q " . � H 4 � 9 . � . . 0
[92165.808958]  520abbf7 c728a626 bcaf3fea 6d0b473b � � . R & � ( � � ? � � ; G . m
[92165.808966]  cf754769 17e8cbf8 4e811884 a5af7e5c i G u � � � � . . . . N \ ~ � �
[92165.808974]  50c29910 7e8bacf5 a757f964 b3f9c5a8 . . � P � � . ~ d � W � � � � �
[92165.808982]  ef780822 250d5703 0c4faf84 a425b495 " . x � . W . % . � O . . � % �
[92165.808990]  073df094 51198d6c 6809fc25 f3c81d7e . � = . l . . Q % � . h ~ . � �
[92165.808998]  8991d5d1 bf4c57ed b7a08914 4957d361 � � . . � W L � . . � � a � W I
[92165.809006]  0900c600 fdeda946 4335dad0 c96614be . � . . F � � � � � 5 C � . f �
[92165.809014]  b3f3cd0e 1f6abb91 39860072 93975b75 . � � � . � j . r . . 9 u [ . .
[92165.809022]  88a309fd d5531ddd a29e5070 a32d2330 � . � . � . S � p P . � 0 # - �
[92165.809030]  5f383e2d 5b63b0c8 28ee46b1 6aa4d929 - > 8 _ � � c [ � F � ( ) � � j
[92165.809038]  f8e05d89 23da8340 5ab959a1 6a60653c . ] � � @ . � # � Y � Z < e ` j
[92165.809046]  af8bacb9 690b73c3 72cccff5 c484e88b � � . � � s . i � � � r . � . �
[92165.809054]  970dbad8 ef87b893 b517b15e 5e9c7b5d � � . . . � . � ^ � . � ] { . ^
[92165.809063]  47077045 0dee762b a794ffaa 4fff050d E p . G + v � . � � . � . . � O
[92165.809071]  0f04e118 00574d57 94e33f4c f7c37e9e . � . . W M W . L ? � . . ~ � �
[92165.809079]  4dc1529c 6f7c2b05 7883d1c6 6544559c . R � M . + | o � � . x . U D e
[92165.809087]  6b4f102c 02fdcc9b 00bd5ea4 a6d3cd7a , . O k . � � . � ^ � . z � � �
[92165.809095]  c27699b9 5d45fcc7 7825aee5 40e1a8ff � . v � � � E ] � � % x � � � @
[92165.809103]  99fa8f13 b89c9c2e 2b072b00 ec543a85 . . � . . . . � . + . + . : T �
[92165.809111]  a7489556 24986365 2a0bb4b2 0b0c29f1 V . H � e c . $ � � . * � ) . .
[92165.809119]  44a3ceb0 97c36e7c c116185f 198f90bb � � � D | n � . _ . . � � . . .
[92165.809127]  7d49b4e3 a8df2183 3ef1116a a66b4035 � � I } . ! � � j . � > 5 @ k �
[92165.809135]  c1e41c18 28774910 17230343 9a921c74 . . � � . I w ( C . # . t . . .
[92165.809143]  1266901a 5ca11e81 0f9b25a5 befc22bd . . f . . . � \ � % . . � " � �
[92165.809152]  cad16148 007381ef 00f59414 446b4c8b H a � � � . s . . . � . . L k D
[92165.809160]  610533fd d6082dbe a676b363 dd486a20 � 3 . a � - . � c � v �   j H �
[92165.809168]  b656a506 776b771a fbd0efdc ccb289c1 . � V � . w k w � � � � � . � �
[92165.809176]  b0b1adff 881b7536 97b39711 a8e4d470 � � � � 6 u . . . . � . p � � �
[92165.809183]  5ef2f838 3053fb35 4ec7292d a83b23c6 8 � � ^ 5 � S 0 - ) � N � # ; �
[92165.809191]  bf145965 ff32c067 b2589af7 55be6ad7 e Y . � g � 2 � � . X � � j � U
[92165.809200]  ddfa17d8 f42391a7 ee7e9cb9 d7b008a9 � . � � � . # � � . ~ � � . � �
[92165.809208]  83b49fed d6aac4dd 09099406 1a33fa8b � . � . � � � � . . . . . � 3 .
[92165.809216]  cd4e6e47 53d143d6 b2d73a15 52874177 G n N � � C � S . : � � w A . R
[92165.809224]  e11ecc1a e2f27562 4feed52b 1963588f . � . � b u � � + � � O . X c .
[92165.809232]  2fb7db5d a5023040 c7efad44 16037bde ] � � / @ 0 . � D � � � � { . .
[92165.809240]  953076e1 7af189fd cabbc6a1 c034438c � v 0 . � . � z � � � � . C 4 �
[92165.809248]  6ec3b290 cc0a5dfd 3e9658ca bd4011c8 . � � n � ] . � � X . > � . @ �
[92165.809256]  6305a493 f16bd05a 50fdff02 6e376661 . � . c Z � k � . � � P a f 7 n
[92165.809264]  26781bbf 68f3d2ee b0ae6e91 9a86d959 � . x & � � � h . n � � Y � . .
[92165.809272]  6101e223 4aec107e d8589ba2 21d6da09 # � . a ~ . � J � . X � . � � !
[92165.809280]  a845d987 ae041e7c 76019f7d ce39f33f . � E � | . . � } . . v ? � 9 �
[92165.809288]  2ca302b3 a087f9ae f469a019 d0c782b0 � . � , � � . � . � i � � . � �
[92165.809296]  a7141a20 c346e163 95e498b8 07b24c9c   . . � c � F � � . � . . L � .
[92165.809304]  e6c1ed9e 442f8c1c 652d28b0 9b0b86cd . � � � . . / D � ( - e � . . .
[92165.809312]  ee58374e bbc48ace 7b10a49f 2616d649 N 7 X � � . � � . � . { I � . &
[92165.809320]  a49749a0 8130a681 0203a0a3 81a21701 � I . � . � 0 . � � . . . . � .
[92165.809328]  9881049b 1ddc2276 e3f69510 540eb837 . . . . v " � . . . � � 7 � . T
[92165.809336]  beef6f68 335c96a6 6ead1a72 cfcc5657 h o � � � . \ 3 r . � n W V � �
[92165.809344]  84cd97ad 10c1c8e0 ce5746e1 b55c7090 � . � . � � � . � F W � . p \ �
[92165.809352]  6d0e7d40 78e0b33b e2c66da2 71b98c7d @ } . m ; � � x � m � � } . � q
[92165.809360]  2b4a4401 6ceb5058 91d846fa 92fc8ec1 . D J + X P � l � F � . � . � .
[92165.809368]  d7a65168 7ed3f959 8f05ba03 53ee313c h Q � � Y � � ~ . � . . < 1 � S
[92165.809376]  8af8e19e 11331715 87d61bb3 c440d8dc . � � . . . 3 . � . � . � � @ �
[92165.809384]  ca23b624 2c67342b 01d15019 d5242697 $ � # � + 4 g , . P � . . & $ �
[92165.809392]  caf054c5 c930157e 88e715dd 66f569b5 � T � � ~ . 0 � � . � . � i � f
[92165.809398]  e2e121df 4feba1c8 2b050481 � ! � � � � � O . . . +
[92165.809406]  /home/vzyinstall/cifs/transport.c: For smb_command 115
[92165.809410]  /home/vzyinstall/cifs/transport.c: Sending smb:  total_len 1362
[92165.817839]  /home/vzyinstall/cifs/connect.c: rfc1002 length 0x27
[92165.817871] Status code returned 0xc00000bb NT_STATUS_NOT_SUPPORTED
[92165.817887]  /home/vzyinstall/cifs/netmisc.c: Mapping smb error code 50 to POSIX err -22
[92165.817891]  /home/vzyinstall/cifs/misc.c: Null buffer passed to cifs_small_buf_release
[92165.817895]  /home/vzyinstall/cifs/sess.c: ssetup rc from sendrecv2 is -22
[92165.817901]  /home/vzyinstall/cifs/sess.c: ssetup freeing small buf f73988c0
[92165.817904]  CIFS VFS: Send error in SessSetup = -22
[92165.946643]  /home/vzyinstall/cifs/connect.c: No session or bad tcon
[92165.946653]  /home/vzyinstall/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 6) rc = -22
[92165.946660]  CIFS VFS: cifs_mount failed w/return code = -22

I have tried with krb5i too, but "server lacks support" says dmesg.
It seems that the NAS only support "MS KRB5", is there a command to use "MS KRB5" in place of "KRB5" with mount.cifs ? (or it is perhaps not fully implemented now ?)

Thanks,

(In reply to comment #13)
> Created an attachment (id=3414) [edit]
> Network capture trace with patch applied
> 
> Okay, I have patch'ed the module, and insmod'ed it.
> Now, the message is:
> vzyinstall@vzy-p1197493:~$ mount.cifs //vzy-filertest/PartageCIFS ~/toto/ -o
> sec=krb5,username=vzyinstall,password=fake
> mount error 22 = Invalid Argument

try to replace this line:
    *secblob = gen_negTokenInit(OID_KERBEROS5, tkt_wrapped);

on this one:
    *secblob = gen_negTokenInit(OID_KERBEROS5_OLD, tkt_wrapped);

in source/client/cifs.spnego.c of samba32 source tree and build modified cifs.spnego. It is not right way but it may help.

(In reply to comment #14)
> (In reply to comment #13)
> > Created an attachment (id=3414) [edit]
> > Network capture trace with patch applied
> > 
> > Okay, I have patch'ed the module, and insmod'ed it.
> > Now, the message is:
> > vzyinstall@vzy-p1197493:~$ mount.cifs //vzy-filertest/PartageCIFS ~/toto/ -o
> > sec=krb5,username=vzyinstall,password=fake
> > mount error 22 = Invalid Argument
> try to replace this line:
>     *secblob = gen_negTokenInit(OID_KERBEROS5, tkt_wrapped);
> on this one:
>     *secblob = gen_negTokenInit(OID_KERBEROS5_OLD, tkt_wrapped);
> in source/client/cifs.spnego.c of samba32 source tree and build modified
> cifs.spnego. It is not right way but it may help.

After replacement & recompilation, I have the same error.

(In reply to comment #15)
> > try to replace this line:
> >     *secblob = gen_negTokenInit(OID_KERBEROS5, tkt_wrapped);
> > on this one:
> >     *secblob = gen_negTokenInit(OID_KERBEROS5_OLD, tkt_wrapped);
> > in source/client/cifs.spnego.c of samba32 source tree and build modified
> > cifs.spnego. It is not right way but it may help.
> 
> After replacement & recompilation, I have the same error.

Could you try to get network capture on cifs session setup and kerberos (port 88) requests at this time.

Created attachment 3418 [details]
Network trace and SPNEGO patch

(In reply to comment #16)
> (In reply to comment #15)
> > > try to replace this line:
> > >     *secblob = gen_negTokenInit(OID_KERBEROS5, tkt_wrapped);
> > > on this one:
> > >     *secblob = gen_negTokenInit(OID_KERBEROS5_OLD, tkt_wrapped);
> > > in source/client/cifs.spnego.c of samba32 source tree and build modified
> > > cifs.spnego. It is not right way but it may help.
> > 
> > After replacement & recompilation, I have the same error.
> Could you try to get network capture on cifs session setup and kerberos (port
> 88) requests at this time.

Here is the .pcap file with cifs session setup & krbreq/krbrep.
You can check if my modification is correct, the patch is included in the tarball.

I have activated the cifs signing on the NAS. Mounting with sec=krb5i return now the same error than sec=krb5 ("STATUS_NOT_SUPPORTED").
When the client try to mount the share, in "Session Setup andX Request", we can see "KRB5 - Kerberos 5" at "Security Blob/SPNEGO/negTokenInit/mechtypes", but, the server doesn't support that, it just support "MS_KRB5", that's certainly why we have "STATUS_NOT_SUPPORTED".
So, can we make a request with "MS_KRB5" in SPNEGO ? (and is it supported in the rest of the session ?).
I don't have see documentation about "MS KRB5", is there big differences with KRB5 ?

(In reply to comment #17)
> Created an attachment (id=3418) [edit]
> Network trace and SPNEGO patch
> 
> (In reply to comment #16)
> > (In reply to comment #15)
> > > > try to replace this line:
> > > >     *secblob = gen_negTokenInit(OID_KERBEROS5, tkt_wrapped);
> > > > on this one:
> > > >     *secblob = gen_negTokenInit(OID_KERBEROS5_OLD, tkt_wrapped);
> > > > in source/client/cifs.spnego.c of samba32 source tree and build modified
> > > > cifs.spnego. It is not right way but it may help.
> > > 
> > > After replacement & recompilation, I have the same error.
> > Could you try to get network capture on cifs session setup and kerberos (port
> > 88) requests at this time.
> 
> Here is the .pcap file with cifs session setup & krbreq/krbrep.
> You can check if my modification is correct, the patch is included in the
> tarball.

Checked patch and it should do pack as MS KRB5.
However looking in the dump I see that sent mechType is still KRB5.
So question is, Are you sure that you use patched cifs.spnego?

(In reply to comment #19)
> (In reply to comment #17)
> > Created an attachment (id=3418) [edit]
> > Network trace and SPNEGO patch
> > 
> > (In reply to comment #16)
> > > (In reply to comment #15)
> > > > > try to replace this line:
> > > > >     *secblob = gen_negTokenInit(OID_KERBEROS5, tkt_wrapped);
> > > > > on this one:
> > > > >     *secblob = gen_negTokenInit(OID_KERBEROS5_OLD, tkt_wrapped);
> > > > > in source/client/cifs.spnego.c of samba32 source tree and build modified
> > > > > cifs.spnego. It is not right way but it may help.
> > > > 
> > > > After replacement & recompilation, I have the same error.
> > > Could you try to get network capture on cifs session setup and kerberos (port
> > > 88) requests at this time.
> > 
> > Here is the .pcap file with cifs session setup & krbreq/krbrep.
> > You can check if my modification is correct, the patch is included in the
> > tarball.
> Checked patch and it should do pack as MS KRB5.
> However looking in the dump I see that sent mechType is still KRB5.
> So question is, Are you sure that you use patched cifs.spnego?
Yes, you all right, for a mysterious reason, the re-packaging & re-installation of Samba with my patch hasn't put the new cifs.spnego !
I have copy/paste it from the source tree and now  I can successfully mount the share from the NAS !
Do you want more information (network trace ...) ?
Do we change the status of the bug ?

(In reply to comment #20)
> Yes, you all right, for a mysterious reason, the re-packaging & re-installation
> of Samba with my patch hasn't put the new cifs.spnego !
> I have copy/paste it from the source tree and now  I can successfully mount the
> share from the NAS !
> Do you want more information (network trace ...) ?
No.

> Do we change the status of the bug ?
That is just workaround not the fix. We just changed SPNEGO envelop not the krb ticket and the server just swallowed it. 
Taking in account that there is no support for mutual authorization and with disabled signing, that is just security hole.

If I recall correctly for MS KRB5 we shall send to kdc a principal passed by a server in neg. responce (mechMic). And it is not passed to cifs.spnego from kernel now.

There is two ways to solve problem:
Extensive:
   add additional parameter for pricipal and add MS KRB5 to sec parameter to the kerberos upcall. IMHO is not the best way.
Systematic: 
   pass to upcall spnego blob as is and allow userspace handler deal with it. That depends whether key api is ready for big blobs.

> pass to upcall spnego blob as is and allow userspace handler deal with it.
> That depends whether key api is ready for big blobs.

I think the current keyctl api allows you to pass callout_data as a blob rather than a string. request_key() still requires a string, so we'd have to switch to using request_key_with_auxdata or something (the auxdata could be NULL here).

The main problem I can see is that the callout_info in the authkey is allocated with kmalloc(..., GFP_KERNEL). If we have a very large secblob then that could fail. What's the max size that this blob would reasonably be? I seem to remember people talking about 64k or 128k as an upper limit when we originally did this work...

(In reply to comment #22)
> > pass to upcall spnego blob as is and allow userspace handler deal with it.
> > That depends whether key api is ready for big blobs.
> 
> I think the current keyctl api allows you to pass callout_data as a blob rather
> than a string. request_key() still requires a string, so we'd have to switch to
> using request_key_with_auxdata or something (the auxdata could be NULL here).
> 
> The main problem I can see is that the callout_info in the authkey is allocated
> with kmalloc(..., GFP_KERNEL). If we have a very large secblob then that could
> fail. What's the max size that this blob would reasonably be? I seem to
> remember people talking about 64k or 128k as an upper limit when we originally
> did this work...

Max blob size could be made configurable via /proc/fs/cifs/...
If somebody can write an experimental patch for the kernel, I could write the corresponding userspace part.

PS:
Can't promise it done earlier that 20th August, I'll be on a vacation from the next week.

I'm not sure what such a tunable would solve. Large in-kernel allocations are always an iffy proposition. They can fail and that may be a big problem.

We're already doing some substantial parsing of the security blob as it is. Would it really be that big of an advantage to send all of this to userspace at this point?

Created attachment 3450 [details]
patchset -- add support for sec=mskrb5 type in upcalls

I'm very wary of trying to pass the whole blob to userspace. It's going to mean relying on large kmalloc's to work (which is always iffy), or we'll have to do some other complex scheme to get it there. It just seems simpler to me to parse out the mechListMIC in the kernel.

This patchset should help us to implement the first method that Igor mentioned in comment #21. This has decode_negTokenInit parse out the mechListMIC, and then pass that in the description string for the upcall.

I don't currently have a working userspace program that corresponds with this, or a good server to test this against, so this is still an RFC. I think it'll work though once the cifs.upcall program is taught how to properly roll blobs for mskrb5.

Thoughts?

The first 2 patches in the previous patchset have already been posted to the mailing list. They're generic fixes that should probably make it in regardless. The other patches do depend on them though...

Created attachment 3483 [details]
Adds support to cifs.spnego for MS_KRB5 wrapping

PS:
patch made against of v3-2-test tree

Created attachment 3484 [details]
Fix length error in wrapping spnego blob

Found in v3-2-test tree
was introduced in:
commit 5f419135ba1acae6bc37692fa77ae1162b62e0e3
Author: Jeremy Allison <jra@samba.org>
Date:   Fri Aug 8 14:33:00 2008 -0700

    Add Derrick Schommer's <dschommer@F5.com> kerberos delegation patch. Some
    work by me and advice by Love.
    Jeremy.

Jeff,

Server lists the most preferred mech as the first entry.
So it would be nice of client to use it. Otherwise to test this we need
find server only with mskrb5.
Here is possible solution:

diff --git a/fs/cifs/asn1.c b/fs/cifs/asn1.c
index 3234a90..cf0151a 100644
--- a/fs/cifs/asn1.c
+++ b/fs/cifs/asn1.c
@@ -577,10 +577,12 @@ decode_negTokenInit(unsigned char *security_blob, int length,
 
                                if (compare_oid(oid, len, MSKRB5_OID,
                                                MSKRB5_OID_LEN))
-                                       use_mskerberos = true;
+                                       if (!(use_mskerberos || use_kerberos))
+                                               use_mskerberos = true;
                                else if (compare_oid(oid, len, KRB5_OID,
                                                     KRB5_OID_LEN))
-                                       use_kerberos = true;
+                                       if (!(use_mskerberos || use_kerberos))
+                                               use_kerberos = true;
                                else if (compare_oid(oid, len, NTLMSSP_OID,
                                                     NTLMSSP_OID_LEN))
                                        use_ntlmssp = true;

Nice work, Igor.

Looks like it all works. I confirmed by network captures that I was able to authenticate to a win2k3 server using mskrb5.

I wouldn't mind reworking the logic in decode_negTokenInit so that we don't need all of these "use_*" bools, but it's probably OK in the short term. I'll clean up the patchset soon and post it to linux-cifs-client.

We'll still need to figure out what to do about the fact that this filer doesn't set SMBFLG2_EXT_SEC as well, but that can probably wait until the other pieces are in place for mskrb5.

The clikrb5.c fix is definitely required for this though. Are you planning to push that patch on samba-technical?

(In reply to comment #30)
> The clikrb5.c fix is definitely required for this though. Are you planning to
> push that patch on samba-technical?

Sent it to samba-technical, hopefully somebody will commit it.

Created attachment 3487 [details]
Adds support to cifs.upcall for spnego MS_KRB5 wrapping

Made patch applicable to today's git tree with cifs.spnego renamed to cifs.upcall.

The MSKRB5 OID part of this is merged (see below).  The use of the mic field as a hint for principal name is not merged - pending technical discussions on samba-technical and linux-cifs-client mailing lists.  This should improve the current situation but I understand Igor's point about the difficulty with DFS initiated implicit authentication.

commit c30d73035dd202d0055ed7ede243e1703c4e9450
Author: Jeff Layton <jlayton@redhat.com>
Date:   Tue Aug 19 21:29:41 2008 -0400

    cifs.upcall: handle MSKRB5 OID properly
    
    When the kernel sends the upcall a sec=mskrb5 parameter, that means
    the the MSKRB5 OID is preferred by the server. This patch fixes the
    upcall to use that OID in place of the "normal" krb5 OID when it
    gets a sec=mskrb5 parameter.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Acked-by: Steve French <smfrench@gmail.com>

(In reply to comment #33)
> a hint for principal name is not merged - pending technical discussions on
> samba-technical and linux-cifs-client mailing lists.  This should improve the
> current situation but I understand Igor's point about the difficulty with DFS
> initiated implicit authentication.

As workaround we can use NTLMv2 in case of DFS, it works. That leaves us without krb5 in some weird DFS setups (in my case it's fault tolerant group
name as a target server in DFS referral).

Currently, we're just using the host passed from the kernel as the principal name. One thing we could also consider is to do a reverse lookup of the IP address and try to use that name as the hostname in the principal. So maybe the order of operations would be

1) try and use hostname passed from kernel as host portion of principal

2) reverse-resolve ip address and try to use that as host portion

...presuming that the PTR records in DNS resolve to the hostname in the machine's principal then that should work. I don't think that it'll be any less secure either (if reverse DNS is compromised then forward DNS probably is too). 

While it may slow things down somewhat, I don't see much issue with having the upcall make several attempts to get a ticket. We don't do upcalls that often, and it's better to have them be a little slow than to fail.

We could also still consider adding a srvprinc= option too, and use that for "0)" here, but I'd rather wait until we have a clear need for it.

(In reply to comment #35)
> Currently, we're just using the host passed from the kernel as the principal
> name. One thing we could also consider is to do a reverse lookup of the IP
> address and try to use that name as the hostname in the principal. So maybe the
> order of operations would be
> 
> 1) try and use hostname passed from kernel as host portion of principal
> 
> 2) reverse-resolve ip address and try to use that as host portion

In my case it will not help because of reverse lookup returns the same name as
a hostname passed to upcall (ft group name). I don't know, may be the target server is assigned several IPs or ft thing implemented on a router.

> ...presuming that the PTR records in DNS resolve to the hostname in the
> machine's principal then that should work. I don't think that it'll be any less
> secure either (if reverse DNS is compromised then forward DNS probably is too). 

In MS networks dns often implemented in a way that allows workstations to do DDNS updates of A and PTR records without any auth, so making principal from a reverse lookup will allow to fake it. Or DNS cache poisoning with fake PTR record will lead to the same result.

If we can't trust to DNS lookups or local cache, That approach will not be safe one either.


> While it may slow things down somewhat, I don't see much issue with having the
> upcall make several attempts to get a ticket. We don't do upcalls that often,
> and it's better to have them be a little slow than to fail.

> We could also still consider adding a srvprinc= option too, and use that for
> "0)" here, but I'd rather wait until we have a clear need for it.

We can just wait for at least one person who would like to use cifs in cross realm environment. 

What do you mean by "Cross REALM environment" ?

We have here a Active directory on a domain and some other data server in others (DNS) domain (totally different from the AD domain), but we can use kerberos without problems (for authenticating users against intranet site by example), thanks to SPNs.

Another question, do you know if "MS_KRB5" support is already enabled in a stable kernel ? (a search in kernel-changelogs for MS KRB5 don't show results, but it looks like that was okay in Samba 3.2.x)

Yes, I believe the MSKRB5 patch made 2.6.27.

The other problem (broken SMBFLG2_EXT_SEC by the filer) is a separate issue. My inclination is to simply call that a server problem and have someone open a bug with netapp.

In fact, I'm going to go ahead and close this as fixed since I think it is against servers that don't have that bug. Anyone with one of these broken filers should probably open a bug with netapp and ask them to fix this.