RPC_IN_DATA 401

https://httpstatuses.com/401

I think, the first access is not authenticated.

regards

mod

Hi,

I thought maybe because I use the option "Use my Rdgateway credential for remote computer" at RDP then the UTM dont like it, so I did disable this option and try to access the internal server with Rdgateway again and this time I had to authenticate twice, but unfortunately still I see the same 401 in the logs.

Thaks

Hi Aresh,

this has nothing to do with the utm. The 401 is returned from the exchange server. I think you have basic/default authentication configured on exchange site. With integrated authentication you should not see the 401.

regards

mod

Hey Aresh.

I think that's just how things work. My guess is that the client tries to access the RCP Proxy unauthenticated first and only after receiving a 401 it authenticates. Wee see this because the UTM is chatty, as it should be.

I see the same on one of my setups:

First contact:

2017:04:06-11:27:37 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="Y.Y.Y.Y" size="13" user="-" host="X.X.X.X" method="RPC_IN_DATA" statuscode="401" reason="-" extra="-" exceptions="SkipURLHardening" time="1104795" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"
2017:04:06-11:27:42 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="Y.Y.Y.Y" size="13" user="-" host="X.X.X.X" method="RPC_OUT_DATA" statuscode="401" reason="-" extra="-" exceptions="SkipURLHardening" time="1124507" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"

Later on, sucess:

2017:04:06-11:28:59 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="Y.Y.Y.Y" size="0" user="-" host="X.X.X.X" method="RPC_IN_DATA" statuscode="200" reason="-" extra="-" exceptions="SkipURLHardening" time="80830352" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"
2017:04:06-11:28:59 utm reverseproxy: id="0299" srcip="X.X.X.X" localip="1Y.Y.Y.Y" size="195082" user="-" host="X.X.X.X" method="RPC_OUT_DATA" statuscode="200" reason="-" extra="-" exceptions="SkipURLHardening" time="75012636" url="/rpc/rpcproxy.dll" server="rds.domain.com" referer="-" cookie="-" set-cookie="-"

I personally never noticed this. Maybe you're being a bit overzealous about this.

Regards - Giovani

Hi,

Thanks for the update,

you are right maybe I should ignore this. Just one more question I did check the log and see this at the top of the bot 403 errors that I didnot see lat time and it says:

Should I also add the remoteDesktopGateway/ aslo to the paths of exceptoins lik /rpc/* and /rdweb/* etc as well?

2017:04:10-12:15:34 securitysrv1-2 reverseproxy: [Mon Apr 10 12:15:34.509920 2017] [url_hardening:error] [pid 29460:tid 4087978864] [client 217.XX.XX.30:46560] No signature found, URI: https://remote.mydomain.nl.nl/remoteDesktopGateway/

2017:04:10-12:15:34 securitysrv1-2 reverseproxy: id="0299" srcip="217.XX.XX.30" localip="62.XX.XX.190" size="284" user="-" host="217.XX.XX.30" method="RDG_OUT_DATA" statuscode="403" reason="url hardening" extra="No signature found" exceptions="-" time="690" url="/remoteDesktopGateway/" server="remote.mydomain.nl.nl" referer="-" cookie="-" set-cookie="-"

Hi Aresh,

yes, you should also create an url hardening excepttion for this path.

regards

mod

Actually, mod, I disagree. Creating an exception for this path would cause the client to try to use the new RDG protocol, which is not supported by UTM. When denying this path the client falls back to RPC over HTTPS (hence the rpcproxy.dll), which is supported by WAF by its builtin OutlookAnywhere support.

Regards - Giovani

Then just ignore my last post ;)

regards

mod

Thank you all for the help

Thanks

could it this be the reson we see the 403 in the WAF logs?

could it this be the reson we see the 403 in the WAF logs?

Yes, it's denied (403) because there's no URL hardening exception for this path. It's expected to be denied and it must be denied if you want to use WAF to protect RDGateway. As I stated before, allowing it would cause the client to use a newer protocol that WAF is yet no able to handle.