mac check in GCM failed

[hi-ko]

alfresco 6.1 CE configured with Kerberos SSO runs fine with smb.dialects=SMB1 but fails with smb.dialects=SMB2,SMB3

alfresco-gobal.properties:

smb.kerberos.realm=D.MYCOMPANY.COM
smb.kerberos.stripUsernameSuffix=true
smb.kerberos.loginEntryName=AlfrescoCIFS
smb.kerberos.debug=true


# fileServersNG SMB server configuration
smb.enabled=true
smb.dialects=SMB2,SMB3
smb.sessionDebug=Socket

# Enable the use of asynchronous sockets/NIO code
smb.disableNIO=false
# Session timeout, in seconds. Defaults to 15 minutes, to match the default Windows client setting.
# If no I/O is received within that time the session is closed by the server
smb.sessionTimeout=900
# Can be mapped to non-privileged ports, then use firewall rules to forward requests from the standard ports
smb.tcpipSMB.port=1445
smb.netBIOSSMB.sessionPort=1139
smb.netBIOSSMB.namePort=1137
smb.netBIOSSMB.datagramPort=1138
smb.WINS.autoDetectEnabled=true
smb.pseudoFiles.enabled=false
smb.pseudoFiles.shareURL.enabled=false

smb.useSPNEGO=true

catalina.out when connecting from a win10 client:

Found KeyTab /etc/ecm-trans_cifs.keytab for cifs/ecm-trans.mycompany.com@D.MYCOMPANY.COM
Found ticket for cifs/ecm-trans.mycompany.com@D.MYCOMPANY.COM to go to krbtgt/D.MYCOMPANY.COM@D.MYCOMPANY.COM expiring on Wed Dec 04 02:33:46 CET 2019
Entered Krb5Context.acceptSecContext with state=STATE_NEW
Looking for keys for: cifs/ecm-trans.mycompany.com@D.MYCOMPANY.COM
Added key: 23version: 0
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 18 17 20 19 16 23.
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
MemoryCache: add 1575387253/000092/A4A3E7A8417AFD2C42F8558757DFB7BFE4743914589ED7453D052FEB95080C1A/test-user_a@D.MYCOMPANY.COM to test-user_a@D.MYCOMPANY.COM|cifs/ecm-trans.mycompany.com@D.MYCOMPANY.COM
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 469935080
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Krb5Context setting mySeqNumber to: 50459810
2019-12-03 16:34:14,085  DEBUG [auth.smb.AlfrescoSMBAuthenticator] [FileSrvWorker10] [SMB] Using OID MS Kerberos5 for NegTokenTarg
 2019-12-03 16:34:14,085  DEBUG [auth.smb.AlfrescoSMBAuthenticator] [FileSrvWorker10] [SMB] Created NegTokenTarg using standard Krb5 API response
 2019-12-03 16:34:14,085  DEBUG [auth.smb.AlfrescoSMBAuthenticator] [FileSrvWorker10] [SMB] Logged on using Kerberos, user test-user_a
 2019-12-03 16:34:14,086  DEBUG [auth.smb.AlfrescoSMBAuthenticator] [FileSrvWorker10] mapUserNameToPerson userName:test-user_a, checkEnabled:true
 2019-12-03 16:34:14,087  DEBUG [auth.smb.AlfrescoSMBAuthenticator] [FileSrvWorker10] Mapped user name test-user_a to person test-user_a
 2019-12-03 16:34:14,092  ERROR [org.alfresco.fileServersNG] [FileSrvWorker11] Error from JFileServer
 org.bouncycastle.crypto.InvalidCipherTextException: mac check in GCM failed
        at org.bouncycastle.crypto.modes.GCMBlockCipher.doFinal(Unknown Source)
        at org.filesys.smb.server.smbv2.b.a(Unknown Source)
        at org.filesys.smb.server.smbv2.e.runProtocol(Unknown Source)
        at org.filesys.smb.server.SMBSrvSession.processPacket(SMBSrvSession.java:1262)
        at org.filesys.smb.server.nio.NIOSMBThreadRequest.runRequest(NIOSMBThreadRequest.java:130)
        at org.filesys.server.thread.ThreadRequestPool$ThreadWorker.run(ThreadRequestPool.java:136)
        at java.base/java.lang.Thread.run(Unknown Source)
2019-12-03 16:34:24,243  INFO  [web.scripts.ImapServerStatus] [http-nio-127.0.0.1-8081-exec-4] Successfully retrieved IMAP server status from Alfresco: disabled
 03-Dec-2019 16:34:32.177 INFO [http-nio-127.0.0.1-8081-exec-4] org.apache.coyote.http11.Http11Processor.service Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986
        at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:484)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:684)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:806)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.base/java.lang.Thread.run(Unknown Source)

[FileSysOrg]

There was an issue with the SMB3 code that was fixed in a recent version of the JFileServer code.

What version of fileServersNG are you using, or what versions of the jfileserver and jfileserver-enterprise jars do you have in the libs/ folder ?.

The latest JFileServer release versions are jfileserver 1.11 (available here https://mvnrepository.com/artifact/org.filesys/jfileserver) and jfileserver-enterprise 1.09 (available here http://www.filesys.org/maven/org/filesys/jfileserver-enterprise/).

Using smb.dialects=SMB2 should work ok, or replace the jfileserver and jfileserver-enterprise jars with the latest versions should fix the SMB3 issue.

[hi-ko]

Thanks for the promt feedback!

I used fileserversng-v61-1.0.3.amp containing jfileserver-alfresco-embed-1.1.8.jar / jfileserver-enterprise-1.0.6.jar
I will build new amp containing latest jars and test again. Couldn't you manage releases not to hunt for git commits? Additionally you could write some lines as release comment ;-)

[hi-ko]

with amp version 1.05 I'm able to connect but get same error on later requests while browsing thru the directories.
Trying @smb.dialects=SMB2@ only seems to work without errors so far.

Work around is to work with SMB2 / not with SMB3

Thanks!