CXLogon-win - LoginListener, deallogin, Couldn't find the user

[COS365]

I'm migrating from Active Directory to Azure. I have installed another instance of NXFilter for use by the Azure users.

I am running NXFilter V 4.6.4.3. My desktops are Windows 10 Pro joined to Microsoft Azure with CXLogon v1.0.5 installed. The first DNS of the desktop points to the NXFilter Master and the second DNS points to the NXFilter Slave. CX Logon is configured to auto register new users and add them to a default group. All desktops use Chrome with the CXForward extension installed.

This all works well most of the time. Every now and again a user will receive an error when visiting a website that they have visited successfully in the recent past. They will receive an error 'website has been blocked'. If it is blocked without a reason it might be from your browser cache'. The AD and Azure instances of NXFilter have similar settings and I have never got this error with AD users.

In the NXFilter log I see a lot of errors
ERROR [01-30 17:03:22] - LoginListener._dealLogin, Couldn't find the user 172.16.19.123, d41d8cd98f00b204e9800998ecf8427e, agentName = CxLogon-win.

Any idea what's causing the website has been blocked error? I have to stop my Azure migration for now.

[support200]

What was the correct username from your CxLogon? Was it Azure username or local username? Was the user logged-in with an Azure username?

[support200]

That error message is actually redundant. Your CxLogon sends an empty Azure username but we try to find a user with its system username in that case. 172.16.19.123 should be logged-in with the system username. We need to remove that redundant message first to find the real problem.

We will get you new ones.

[support200]

These are the new versions,

https://pub.nxfilter.org/imsi/nxfilt....5.2-azure.zip
https://pub.nxfilter.org/imsi/cxlogon-1.0.6-win.msi

NxFilter v4.6.5.2 will print out the message for Azure user finding failure on DEBUG level. CxLogon v1.0.6 will send Azure username only if it finds one.

Several things you need to think about,

1. Was it for just one user or every user?

2. You can enable debugging for CxLogon and see if what usernames it actually detects.
- In c:/program files/cxlogon/conf/log4net.xml, you can change INFO to DEBUG.

3. If you enable debugging for your NxFilter, It will prints out 'RHr, Login redirection for 172.16.19.123' if it's really from Login Redirection.
- To enable debugging, https://tutorial.nxfilter.org/i-faq.php#enable-debug

If you want to rule out Login Redirection, you may add a default user associating 172.16.0.0 – 172.31.255.255 range. If you still get that problem with the default user associating to your whole IP range, it's not from Login Redirection.

[COS365]

This is an old thread but the problem has started again. At the time I upgraded nxFilter, restarted the server and the problem went away. I am currently running 6.6.6.2 with cxlogon 1.0.6. The problem has returned for certain users.

I enabled nxfilter DEBUG. In the logs I see the following for the affected user:

DEBUG [04-15 09:42:29] - RHr, RH #5, block.nxfilter.org, rqSize = 0, rDc = 1, rTtl = 0, rType = 1, cltIp = 172.16.5.69.
DEBUG [04-15 09:42:29] - RHr, Domain redirection by block domain for 172.16.5.69.
DEBUG [04-15 09:42:29] - LoLdCS, /CXB 8560a768c7eb3a8bf3f34e0b754fc7d6 bmRpZGlhbWFrYWNoaW5hemFla3A= win
DEBUG [04-15 09:42:29] - LoginListener._dealCxlogon, uname = ndidiabcdefghij, azUname = .
DEBUG [04-15 09:42:29] - LoginListener._dealLogin, Login session refreshed by CxLogon-win request for 172.16.5.69, ndidiabcdefghij.

[support200]

Last time, there's 'Couldn't find the user' message. It means that CxLogon sends a username but NxFilter couldn't find it. This time there's no error message. The user 'ndidiabcdefghij' has already logged in and CxLogon sends the username again and NxFilter refreshses the login session.

What happened on 172.16.5.69? You get NxFilter login page on the browser?

'block.nxfilter.org' is a special domain for NxFilter. It responds with its block redirection IP for the domain. So, that redirection is just for internal use.

[COS365]

The user is using Chrome and getting 'Your connection is not private. Attackers might be trying to steal your information' error. The cert for the blocker page is block.nxfilter.org.
If they refresh the page often enough the page will eventually work.
It they copy and paste the link into an Incognito tab the link works!

[support200]

I don't think it's CxLogon problem. CxLogon is about user authentication. If it fails then you may get NxFilter login page. Maybe something was blocked but didn't appear on your browser as it's on HTTPS. https://tutorial.nxfilter.org/d-cxfo...k-on-https.php

Do you see nothing blocked for him around the time?

[COS365]

I have 2 installations of nxFilter on the same network. One supports Active Directory while the other supports the Azure AD users. The DNS address is different depending if the computer is to support AD or ADD. I notice that cxForward has the AD server IP address. I have a meta name on the default page pointing to ADD but I understand this method is no longer used. How does cxForward determine the server IP address?

Does cxForward have any form of caching as the affected users were previously using AD?

Do both installations have the exact same certificate fingerprints? I'm wondering if I can determine the cert being used when the user is getting the 'not private' error.

[support200]

In old days, we use a kind of special domain to find out the current DNS server. Since Google forccing HTTPS, it's not possible and we make it querying one of our servers outside your network. So, it's always your master node IP if you use clustering. If you use 2 servers without clustering, it makes a race condition. We may need to resolve it inside CxForward.

There's no certification being used by CxForward. It just forwards your browser to NxFilter block page using HTTP instead of HTTPS.

Why don't you use AD and ADD both on the same server? Any reason not to do that?

[COS365]

The problem mostly happens when a new ADD user first logs in to the computer. If I restart nxFIlter Master and then nxFilter Slave the user can browse as normal.

[support200]

What do you do when an ADD user logs in? Switch DNS server for him?

[COS365]

DNS settings are configured using DHCP. The first DNS IP is the Master, the second DNS IP is the Slave.

[support200]

So the DNS server is always the same for your users? I thought you use 2 servers, one for AD and another for ADD.

I guess you don't use clustering and they are 2 stand alone servers. You use AD one as the primary and ADD one as the secondary?

[COS365]

Azure users are configured to use nxFilter Master and Slave. AD users use another stand alone version of nxFilter.