calc2014

Hi @"scoutt" it sounds like a configuration problem or code issue. If you try with the GUI version of WinSCP this will verify the server is set up correctly and then you can use the command-line tools in WinSCP to transfer files 'silently' without the need for interaction. There is documentation here:…

Great, yes I'm always happy to see further features to reduce that!!

Please submit to support so this is included as a formal feature request

Yes I've seen this before @"chrisrow" if you contact support with the issue they should be able to help.

Please see this related thread: https://thwack.solarwinds.com/product-forums/serv-u-ftp-mft/f/forum/95064/https-broken-after-upgrade-to-15-3-1-from-15-3-0

Just to clarify, you'll need to get the cert re-signed or issue a self-signed one once you create a new CSR and key, as the old cert wont match.

If you need to get back up and running, recreate your CSR and private key for the SSL certificate and it should resolve it. I've only seen it once and it appears to be to do with this, an old cert or key format and creating a new one resolved it. I would recommend you raise it with Solarwinds Support though as they may be…

It was from a new CSR, so maybe it's the old private key format that was not supported?

Thanks @"tjones2019", yes I did that exact check and SSL Labs simply said it could not connect. Think by default TLS1.1 is no longer supported in 15.3.1 so I wonder if certain certificates if they are old dont have capability to work with TLS1.2 or 1.3, seems odd but thats the only explanation I could think of?

I saw this but only in for one certificate, everything else was fine. We ended up reissuing the certificate from a different provider and it was fine. Not sure what would cause that but maybe 15.3.1 doesnt support some specific certs? @"ivodlouhy" do you know if a change to OpenSSL in 15.3.1 may be the reason for this…

I dont believe wildcards are supported for File Management rules as the path is validated

I dont believe wildcards are supported for File Management rules as the path is validated

Thanks @"66chevelle", changing the NTFS permissions will affect the whole of serv-u rather than specific users in it, so I would not generally recommend it. However if you have a very specific setup and all users have this same permissions requirement I can see why it would work. If you need more users with different…

Ahh I understand now. One option you could do as a workaround is to add IP Access rules on the domain users, then they cannot login even if the password was used. Or, create a separate domain for admin users and only have a listener on a local LAN IP, and optionally add IP Access rules at the domain level.

Thanks for the info, have you created your global administrators at the Server level or Domain level. It is possible to have 'Global Administrators' within a domain rather than specifying them at the global level in Serv-U. Maybe this will help you use the same MFA method you have in place for domain users?

Should be doable with any SFTP C# library as Serv-U supports the standard SFTP protocol. What library are you using? Are you getting an error? Make sure you use an SFTP library and not FTPS if you want to use port 22 as they are two sepatate protocols

Could you show us a screenshot of how your global accounts are set up? I dont think there is an option for LDAP outside of a domain. What is the purpose of the Global Accounts you have setup?

If you are adding "Directory Access" permissions, you can untick the "inherit" option on the top level folder (above Inbound and Outbound) and then you can specifiy explicit permissions per folder.

Please open a ticket with Solarwinds to check that and let us know as I think only they will be able to confirm for you.

You can add IP Acess rules to block IPs / ranges / networks in Serv-U at various different levels. However if it is a big list, you may want to add them to the server's firewall or a firewall outside of the server to prevent them connecting. It would be useful to have an ability to add large lists by importing into Serv-U…

@"npatterson" how have you implemented MFA on the domain accounts using LDAP? Is this for web based logins?

I've seen this without the Serv-U load balancer, I think @"ivodlouhy" may have been referring to external load balancers. For example, I have seen this when a user was behind a service like https://www.iboss.com/

Thanks @"ivodlouhy" really appreciate you looking into this.

@"ivodlouhy" This seems to be a common problem since 15.2.5 continues to exist in 15.3. Please could this be looked into a fixed? I'm getting a increasing number of user reporting the same issue as well.

Is this a Serv-U specific question @"cloudytechi147"?

Yes, if you have all the logging on for SFTP, particular the detailed logging it will hit your CPU as almost every packet is logged. That level of logging should really only be for debugging as it is not useful otherwise.

Thanks for the detailed report @"66chevelle". I've also seen this error. It seems to be relativly rare but nearly always is related to the user having some kind of Web Filtering / SSL decryption in place. There was a change in 15.2.5 that related to XSS protection changes that may be being triggered by changes to headers…

Ah, maybe its not marked as a question, no worries.

Great, thats good to hear. Please accept the above as the 'solution' / answer.

Your original example of 49.88.112.1-49.88.112.254 I think would just be 49.88.112.* and then your other request above 221.176.0.1 through 221.183.255.255 and 221.192.0.1 through 221.239.255.255 I think would be.. 221.176-183.*.* and 221.192-239.*.* Let us know how you get on!