Questions

Has anyone experienced this before? Event ID 50

Tags:
+
0 Votes
Locked

Has anyone experienced this before? Event ID 50

kiroboy
For the past three days I have been getting event id 50.

I have read the Microsoft KB article about it and I plan on following their troubleshooting steps.

What concerns me though is that on each day it appeared it was around ten times in a row, one or two seconds apart.

To me this makes me think some rogue computer outside our network is trying to log in remotely.

Has anyone here noticed something similar? Any suggestions?

Additional info: this started happening after I gave an outside client an RDP icon on their desktop to log in to one of our servers.

(also, this pc had just been returned from a 'hole in the wall' pc repair shop; the client said they 'messed up' the computer instead of fixing it)

When I went to 'start-run..' and launched 'mstsc' (remote desktop), the IP address field was autofilled with someone else's public IP address.

When I asked the client if they had any IT people that came in for anything, they said 'no'.

So I wonder if this machine is compromised somehow and is loaded with some kind of bot that could be trying to hit our server through RDP.
  • +
    0 Votes
    Toolman5774

    When I have seen this before, it was due to the security settings of the RDP client software. I think the RDP 6.0 client and above have some additional protocols intended to verify both the client and host, which aligns with Terminal services updates on the server end. If the machine's client is below 6.0, they may not have the required authentication methods available, thus generating the error. I would check into those.

    +
    0 Votes
    Curacao_Dejavu

    http://www.eventid.net/display.asp?eventid=50&eventno=606&source=TermDD&phase=1

    lots of mention about encryption and certificates.
    so if you are using those, and the pc is "messed up" that could be the cause.

    does this correspondence with the time that the client is logging in ?
    If nothing else I would start at that pc end and not the server end.

    +
    0 Votes
    kiroboy

    What worries me is the time of the events. They are at 12, 1, 5 and 6am.

    I have no clients that would be logging in at those times.

    Is there a way for me to capture the IP addresses of any devices attempting remote access?

    Especially these attempts mentioned above, which all failed.

    +
    0 Votes
    seanferd

    Unless your logging level is turned way down.

    You could also try Wireshark, in case this occurs again, but set up filters before packet capture logging or you may run out of disk space overnight.

    --Oh, and did you look up any of these mysterious IP addresses to see, at least generally, who owns them? (Which ISP, company, etc.)

    +
    0 Votes
    Toolman5774

    I believe terminal services captures the NIC IP of the client, and computer name, not the external IP. For that, you would look at your firewall logs to see what the NAT'd IP would be, but I could be wrong.

    +
    0 Votes
    Curacao_Dejavu

    toolman is correct, you will only see the client's ip.

    "Those should be in the server logs.
    Unless your logging level is turned way down."
    Not sure about this.

    I take you have no international clients ?

    You will have to look at the firewall logs indeed on who's was connecting to port 3389.

    +
    0 Votes
    kiroboy

    I wonder if this has to do with pc's in our internal network..

    I looked at the event log of an internal machine and twice a day it is logging event id 15, which has to do with AutoEnrollment and certificates.

    I feel this is related to event id 50, so I will check the event logs of all our machines and in our domain controller I will delete the three keys from the registry that Microsoft suggests.

    I will do this over the weekend and I will post my observations in two days.

  • +
    0 Votes
    Toolman5774

    When I have seen this before, it was due to the security settings of the RDP client software. I think the RDP 6.0 client and above have some additional protocols intended to verify both the client and host, which aligns with Terminal services updates on the server end. If the machine's client is below 6.0, they may not have the required authentication methods available, thus generating the error. I would check into those.

    +
    0 Votes
    Curacao_Dejavu

    http://www.eventid.net/display.asp?eventid=50&eventno=606&source=TermDD&phase=1

    lots of mention about encryption and certificates.
    so if you are using those, and the pc is "messed up" that could be the cause.

    does this correspondence with the time that the client is logging in ?
    If nothing else I would start at that pc end and not the server end.

    +
    0 Votes
    kiroboy

    What worries me is the time of the events. They are at 12, 1, 5 and 6am.

    I have no clients that would be logging in at those times.

    Is there a way for me to capture the IP addresses of any devices attempting remote access?

    Especially these attempts mentioned above, which all failed.

    +
    0 Votes
    seanferd

    Unless your logging level is turned way down.

    You could also try Wireshark, in case this occurs again, but set up filters before packet capture logging or you may run out of disk space overnight.

    --Oh, and did you look up any of these mysterious IP addresses to see, at least generally, who owns them? (Which ISP, company, etc.)

    +
    0 Votes
    Toolman5774

    I believe terminal services captures the NIC IP of the client, and computer name, not the external IP. For that, you would look at your firewall logs to see what the NAT'd IP would be, but I could be wrong.

    +
    0 Votes
    Curacao_Dejavu

    toolman is correct, you will only see the client's ip.

    "Those should be in the server logs.
    Unless your logging level is turned way down."
    Not sure about this.

    I take you have no international clients ?

    You will have to look at the firewall logs indeed on who's was connecting to port 3389.

    +
    0 Votes
    kiroboy

    I wonder if this has to do with pc's in our internal network..

    I looked at the event log of an internal machine and twice a day it is logging event id 15, which has to do with AutoEnrollment and certificates.

    I feel this is related to event id 50, so I will check the event logs of all our machines and in our domain controller I will delete the three keys from the registry that Microsoft suggests.

    I will do this over the weekend and I will post my observations in two days.