I am implementing TURN protocol for ICE. If the remote party sends its HOST,SERVER-REFLEXIVE and RELAYED-REFLEXIVE addresses in SDP ,should we create permissions to ALL(host,SERVER and RELAYED ) the remote candidates in the TURN server OR just to RELAYED-REFLEXIVE address ?
Thanks and Regards
I believe you need to set permissions for all known IP addresses of the remote host. The usual connectivity with TURN will be with the SERVER-REFLEXIVE address of the remote host.
Related
We are in the process of turning off NTLM in our environment for both inbound and outbound traffic via GPO. In our lab testing we have encountered the following when blocking inbound NTLM on a remote host:
RDP'ing to the remote host with inbound NTLM blocked via cross-forest generated a CredSSP error message.
Setting Encryption Oracle Remediation to either Mitigated or Vulnerable as a workaround did not work.
Turning off NLA on the remote host as a workaround will allow cross-forest RDP
I have tried applying "Allow delegating fresh credentials" via policy on the remote host but it is still getting the CredSSP error
I have also tried setting the policy on the remote host to use SSL for "Require use of specific security layer for remote (RDP) connections", and I still got the same CredSSP error.
What did work is if I try to RDP from the same forest to the remote host, it will allow the connection and I can confirm it is using Kerberos for RDP instead of NTLM.
Another observation is once the same forest RDP worked on the remote host, cross-forest RDP connection on the remote host with the blocked inbound NTLM will now work.
Has anyone encountered something similar like this before?
If so, has anyone found a solution for cross-forest RDP to work on a remote host with blocked inbound NTLM without the need to pre-auth on the remote host in the same forest?
The Encryption Oracle Remediation error is a red herring because it uses the same error code as the NTLM is not available error. Unless you haven't patched in 3 years it'll likely never be the Encryption Oracle Remediation issue. It's really just that it tried to fallback to NTLM and policy said no.
In all likelihood the issue is that the client can't find or communicate with a domain controller to do NLA.
The client must find the user's domain first (domain A). From there it authenticates their password. It then asks to get a ticket to the machine. The machine isn't in the user's domain so it creates a referral ticket to where it thinks the machine is (domain B).
The referral is handed back to the client and the client tries to find a DC to where the referral is supposed to go (domain B). The client sends the referral to domain B and asks for a ticket to the machine. The domain controller either finds the machine and issues a ticket for it, or says it doesn't know and offers a referral to another domain (domain C) and you try again, or it just fails saying no machine can be found.
All of this occurs from the client's perspective, not the target machine's perspective. This happens before the client even pings the target machine (ish). This is why disabling NLA appears to resolve the issue.
So there are a handful of reasons why this happens:
You used an IP address -- this is a straight-to-NTLM scenario. Kerberos doens't do IP addresses by default. You can turn it on, but it won't scale.
Client can't communicate with a DC in user's domain (domain A). Networking issue, client needs line of sight to domain controller, plus DNS.
Client can't communicate a with DC in the target machine's domain (domain B). Still a networking issue, client needs line of sight to domain controller, plus DNS.
You're not providing a proper fully qualified name and the user's DC can't figure out what forest it should refer to. You can enable Forest Search Order and it'll maybe help, or you can type in the fully qualified machine name.
This isn't an exhaustive list but these are the most common causes.
References:
https://syfuhs.net/windows-and-domain-trusts
https://syfuhs.net/how-authentication-works-when-you-use-remote-desktop
I also had a similar issue when using the DOMAIN\username login ; using the UPN (username#domaine.com) worked for me.
My understanding is using the UPN allows the client to know the DNS domain name, which then allows it to discover the DC of the remote domain through DNS resolution.
NB : my setup was from a workgroup server so not exactly the same as yours; YMMV.
I no longer have the ability to receive messages from a port at a remote ip address. I can currently ping the remote ip address with no problem. I have a python program that tries to create a socket that connects to that remote port/ip address, but it indicates that the port is closed.
I assume this is a firewall issue. Is this a correct assumption? Who's firewall is to blame, mine or the one at the remote location?
Thanks
I assume this is a firewall issue. Is this a correct assumption?
Not necessarily. It might be that there is simply no service running at the IP and port you are trying to reach.
Who's firewall is to blame, mine or the one at the remote location?
If a firewall is too blame at all it might be at anywhere between the client and the server, i.e. at the client, at the server or at some router or other middlebox in between.
I'm trying to implement a web server on my pc, connected to router.
Since my PC is connected to router, It identifies private IP address, starting with
192.168...
However,it could not accept any clients that is not connected to the same router, even I specified tried with public IP address.
Is it possible to implement Web server that can be accept clients from anywhere with my PC connected to local router?
Or should I connect my web server directly to public IP directly without router?
It'll be pleasure to learn from your answers.
The problem may be, that your web server routing may not be configured correctly to your external IP, or your web server ports may be blocked, or another possibility is that your firewall is blocking your service connections outside the local network.
So, a solution to misconfiguration would be, to forward your port to your internal IP of the web server from your router menu.
And, for the case of firewall blocking, you may give special access to your web server through the firewall by setting inbound and outbound rules.
And if all that is correct then most probably your ISP(Internet Service Provider) is not allowing ports to be opened to you, maybe due to dynamic IP or service restrictions.
For the similar problem, you may refer to my answer to another post Here
What router do you have? go into the router using a web browser, mine is 192.168.0.1 with username and password as admin. or username admin, password blank.
Then set a dmz route or for port forwarding 80 to you own internal IP address.
I need to run an XMPP server for IM with end-to-end encryption and voice calling. I'm trying to set up Prosody, but is it possible to run an XMPP server without a domain name? Without own DNS server and VPN network between clients?
Short Answer: Yes.
You can still configure a XMPP domain for your server. According to the standard, it doesn't has to be an DNS Name or IP address. Something like myserver is fine. Quoting RFC 7622 ยง 3.2:
The domainpart for every XMPP service MUST be a fully qualified domain
name (FQDN), an IPv4 address, an IPv6 address, or an unqualified
hostname (i.e., a text label that is resolvable on a local network).
But if you don't have a DNS name, then clients won't know automatically how to reach your server. Which means you have to configure the IP address and the port in every client.
You can use an IP address instead of a domain name, but if that address will be changing on a regular basis, you'll probably need modifications to standard XMPP servers and clients, as they'll not be expecting that.
I went through many Prosody tutorials and I think it is not possible to set up server based only on IP address and using SSL. I even have not found how to configure Prosody on local network with SSL and resolvable name like raspberry.local. My client always gave server not found, or incorrect communication.
Recently we got a new server at the office purely for testing purposes. It is set up so that we can access it from any computer.
However today our ip got blocked from one of our other sites saying that our ip has been suspected of having a virus that sends spam emails. we learned this from the cbl http://cbl.abuseat.org/
So of course we turned the server off to stop this. The problem is the server must be on to continue developing our application and to access the database that is installed on it. Our normal admin is on vacation and is unreachable, and the rest of us are idiots(me included) in this area.
We believe that the best solution is to remove it from connecting to the internet but still access it on the lan. If that is a valid solution how would this be done or is there a better way? say blocking specified ports or whatever.
I assume that this server is behind a router? You should be able to block WAN connections to the server on the router and still leave it open to accepting LAN connection. Or you could restrict the IPs that can connect to the server to the development machines on the network.