this needs to be fixed to support SMBv2/3 rapidly, inline with guidance from Microsoft for mitigation of WannaCry and future exploits against the SMBv1 protocol.
Current stance from Cisco of "just enable SMBv1 again" isnt acceptable.
I am also currently facing this. SMBv1 is insecure and cannot be used. If Cisco doesn't do something about this we may have to decommission the product and go with a vendor who does support proper protocols.
Can anyone give insight to the AD agent that can be installed on the AD servers? Would this still require SMB at all to authenticate users?
There isn't an agent that gets installed on the AD servers.
You can deploy the CDA, a VM that is given access to the AD boxes. It scrapes the EventLog to get logins and IP's and passes that info to the WSA (and ASA).
You can also use ISE to do something similar.
Thank you Ken,
That clears some things up for me. Do you know if the solution via CDA would utilize SMBv1 at any point? I cant stress how important moving away from SMBv1 is as Thomas mentioned above.
We're currently using the CDA, however this still requires a domain join on the WSA (even for transparent identity) which still leverages SMBv1
Thank you Thomas,
That helps so I don't need to waste time going through an approval process to test it. Hopefully CIsco considers this a top priority.
they really dont class it as urgent per their own annoucement:
Support for SMBv2 and SMBv3 protocols on WSA is currently under development, and will be released for existing, and future releases of WSA by Q4CY17.
needless to say, we are displeased and are speaking with cisco regarding this, i recommend other do the same, more noise and cases that are raised for this will push it up their development timeframe.