Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 19 replies
  • Answers 1 answer
  • Subscribers 19 subscribers
  • Views 18204 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

User authentication against firewall from Terminalserver not working properly

LHerzog

Were having Windows TS with Intercept X. The TS is registered on the firewall (SFOS 19.5.1) as "Citrix Server".

The user that login to the TS are authenticating also against the firewall through the Intercept-X client on the TS. This is working generally.

But for a while now, we're getting complaints from changing users, saying they cannot access internet or internal servers. When checking, we see, their TS user session is not authenticated against the firewall.

We ask them to log off and log in again to the TS. Most of the times, this works after 2 or 3 attempts and their user session from the TS appears in the list of authenticated users on the firewall and they can proceed accessing internet and internal servers (based on FW rules with user authentication).

This is a strange behaviour and I'd like to know how we should proceed analyzing the issue.

Any idea?

TS has Endpoint EAP



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to LHerzog

    problem could be catched while debug running. I see no obvious issue in it except the firewall not getting the new username from the thin client.

    usually you would find this in the access_server.log when a SATC login is successful:

    INFO      May 08 06:35:20.900921Z [access_server]: PCA called for 172.16.xxx.xxx
    DEBUG     May 08 06:35:20.900926Z [access_server]: (should_process_login_request): Started 172.16.xxx.xxx-5 request from SATC
    DEBUG     May 08 06:35:20.900931Z [access_server]: (lc_utf8_bytes): lowercase = 'username'
    DEBUG     May 08 06:35:20.900935Z [access_server]: process_citrix_login_request: SESSIONID:'5',IP:'172.16.xxx.xxx-5',USER:'username',DOMAIN:''

    in our case, there is nothing. A few minutes later or earlier, other SATC user logins from the same ThinClient / IP were successful.

    filed a support case: 06506059

  • 0 in reply to LHerzog

    just an update

    support case is still going on. sounds like the logs they have include debug are not enough at this stage:

    - full process monitor log while login of an affected user

    - on Endpoint all NTP components in debug, not only SNTPService

    - Firewall access_server.log in debug

    today I see several logs on the firewall access_server.log like this:

        Line  97: ERROR     May 09 07:09:26.171923Z [access_server]: (_sqlite_db_handle_get_liveuserinfo): GET_LIVEUSER_INFO_TO_LOGOUT found no entries for IP 172.16.xxx.xxx-7 (sqrs 101)
        Line 113: ERROR     May 09 14:55:43.912436Z [access_server]: (_sqlite_db_handle_get_liveuserinfo): GET_LIVEUSER_INFO_TO_LOGOUT found no entries for IP 172.16.xxx.xxx-7 (sqrs 101)
        Line 122: ERROR     May 10 06:37:41.917940Z [access_server]: (_sqlite_db_handle_get_liveuserinfo): GET_LIVEUSER_INFO_TO_LOGOUT found no entries for IP 172.16.xxx.xxx-4 (sqrs 101)
        Line 123: ERROR     May 10 06:43:28.734170Z [access_server]: (_sqlite_db_handle_get_liveuserinfo): GET_LIVEUSER_INFO_TO_LOGOUT found no entries for IP 172.16.xxx.xxx-7 (sqrs 101)

    Yesterday we switched firewall HA nodes. maybe that is a leftover from there. Will reboot the Terminalserver tonight.

    is it expected, that the RDP Session ID does not match the session ID reported by SATC to the firewall?

    example: RDP Session 9 appears as 172.16.xxx.xxx-13 on the firewall:

    User xxxx@domain.local of group Open Group logged in successfully to Firewall through AD authentication mechanism from 172.16.xxx.xxx-13

    I thought that the session ID would be equal on both sides but I cannot remember exactly and have no documentation of that part.

  • 0 in reply to LHerzog

    the case is back at the network security  team because they say it is not a client issue. lets see.

    case is not progressing currently

  • +1 in reply to LHerzog

    It looks like we have a development ticket opened for this issue as well. This is logged under the ID "WINEP-45479". This was identified just recently after a review from our L3 team. It seems the case was transferred to Endpoint support just after this was identified, as the development ticket is also with our Endpoint developers.

    Correction: The case was transferred to our network team so that information is available from both sides to progress the investigation.

    I will follow up with our support team to ensure the case is progressing smoothly.

    Kushal Lakhan
    Team Lead, Global Community Support
    Connect with Sophos Support, get alerted, and be informed.
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  - Visit Sophos Techvids
  • 0 in reply to LHerzog

    to me it looks like the endpoint has issues recognizing the correct RDP session ID.

    In most cases I cannot find correct RDP Session ID of a user in the sntpservice log - it appears as an other ID. posted that already before.

    Today Support did the whole debug thing again in a remote session and updated me that they found that a login of a user is logged as logout.

    weird things going on.

    back again to the client team. just as mentioned here

  • 0 in reply to LHerzog

    Case is still open, currently at Dev to recreate issue on their side. I hope they do. On the other hand, we have a "working" life demo with the issue still ongoing....

    Today I noticed the opposite issue:

    A user that is no longer logged on a terminalserver, still has a Thin-Client session on the firewall.

  • 0 in reply to LHerzog

    You don't use STAS too for the same network?

    doc.sophos.com/.../index.html

    I had a similair strange issue with STAS tho. We used 2 different mailboxes (2 AD Accounts) sometimes STAS used the 2nd AD Account which didn't had the right perms for http access. So the use with his logged in AD Acc in Win10 got blocked due to the 2nd AD Acc Mailbox. Pretty weird too.

  • 0 in reply to LHerzog

    support case still going...
    a file ...netfilter/xt_LOG.ko has been replaced with a debug version to find out what's happening.
    I hope they do.

Unfiltered HTML