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

STAS Logon Fails because of wrong credentials

Hi Guys,

 

SFOS 17.5.8 MR-8

STAS 2.5.0.

 

we currently have the situtation that users can not authenticate to the firewall via the STAS.

In the authentication Log via LogViewer we get the following error.


"User XXXXX failed to login to Firewall through AD authentication mechanism from 192.168.XX.XX because of wrong credentials"

All users get get displayed on the stas via live users.

Even the connection between XG and STAS is working.

I would assume a problem on the AD server, but the login works if we log in with the AD user ID on the user portal.

 

Attached is a Part of the STAS log for a failed logon.

MSG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_workerthread_wmi: logging on user '[DOMAIN]\TestUser' on '192.168.0.XX
MSG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_handle_logon_req: Request received from CR
MSG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_init_userinfo_common: CreateTime: 1570600091
MSG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_init_userinfo_common: ExpireTime: 1570600696
MSG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_init_userinfo_common: LogonType: 1
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : dca_filter_by_username
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : userdb_handle_duplicate_userinfo: select query: SELECT * FROM UserInfo WHERE wrkst_ip=='192.168.0.XX';
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : userdb_insert_userinfo: no matching userinfo found
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : userdb_insert_userinfo: UserInfo Successfully Inserted
MSG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_handle_logon_req: new userinfo added
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : list_add_tail: first element added
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : wrkstpoll_handle_logon_req: user logon request enqueued to XG Update Queue
ERROR    [0x5444] 09.10.2019 07:48:11 : USERINFO WAITING INFINITE
DEBUG    [0x5444] 09.10.2019 07:48:11 : list_remove_head: last element removed
MSG    [0x5444] 09.10.2019 07:48:11 : SSOclient_thread: got userinfo: USER: domain.com\TestUser <-> Flags: 5
DEBUG    [0x5444] 09.10.2019 07:48:11 : SSOclient_filter_CR_subnet: Entering filter function
DEBUG    [0x5444] 09.10.2019 07:48:11 : SSOclient_filter_CR_subnet: authnet not specified, send request to XG
ERROR    [0x5444] 09.10.2019 07:48:11 : SSOclient_update_CR: domain name is there with length 13 , domain.com
ERROR    [0x5444] 09.10.2019 07:48:11 : USERNAME TestUser Length 5
ERROR    [0x5444] 09.10.2019 07:48:11 : WORKSTN IP 192.168.0.XX Length 13
ERROR    [0x5444] 09.10.2019 07:48:11 : DOMAIN domain.com Length 14
ERROR    [0x5444] 09.10.2019 07:48:11 : SSOclient : PACKET SIZE 243 㐲3
DEBUG    [0x5444] 09.10.2019 07:48:11 : net_send: bytes sent: 243
DEBUG    [0x5444] 09.10.2019 07:48:11 : net_send: full packet sent
MSG    [0x5444] 09.10.2019 07:48:11 : SSOclient_thread: Logon/Logout Update sent to: 192.168.0.XX
ERROR    [0x5444] 09.10.2019 07:48:11 : GETTING (USERINFO) FROM QUEUE
DEBUG    [0x5444] 09.10.2019 07:48:11 : list_remove_head: list is Empty
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : threadpool_finishnotify: Thread ID: 0x7a3c
DEBUG    [0x7a3c] 09.10.2019 07:48:11 : threadpool_finishnotify: Reset Event

 

What else could be the cause ?

 

Kind Regards,
Max



This thread was automatically locked due to age.
Parents
  • Max,

    Check all the steps from this kb:

    Check that from dc to XG, porta 6060 6677 are open.

    Regards

  • Hi Luk,

    thank you for your feedback.

    I see communication between XG and DC.

    XG135_XN03_SFOS 17.5.8 MR-8# tcpdump -ni br0 host 192.168.0.1 and port 6060 or port 6677
    tcpdump: Starting Packet Dump

    15:05:41.271248 br0, OUT: IP 192.168.0.1.59702 > 192.168.0.2.6677: UDP, length 20
    15:05:56.062431 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:06:26.077108 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:06:56.092494 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:07:26.106649 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:07:56.121363 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:08:26.136176 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:08:41.495264 br0, OUT: IP 192.168.0.1.59702 > 192.168.0.2.6677: UDP, length 20
    15:08:56.151263 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:09:22.455296 br0, OUT: IP 192.168.0.1.59702 > 192.168.0.2.6677: UDP, length 21
    15:09:26.166158 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:09:56.180795 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:09:56.379624 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 249
    15:09:56.379779 br0, OUT: IP 192.168.0.1.6060 > 192.168.0.2.55969: UDP, length 22
    15:10:26.195861 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:10:56.210713 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11
    15:11:26.225252 br0, IN: IP 192.168.0.2.55969 > 192.168.0.1.6060: UDP, length 11

    Kind Regards,

    Max

  • Max, did you create the Authentication Server on the XG and the collection group as described in the KB?

    Regards

  • Hi Luk,

    yes, users can authenticate via the UserPortal with their AD credentials.

    The server order is the same as for the firewall authentication.

    Thank you for your help!

    Max

  • so, userportal works as expected? I mean, users are successfully authenticated?

  • Hi Guys,

    @

    that's exactly what amazes me.

    If I log in to the user portal with an AD user, authentication works.

     

    @  

    Thank you for the reply, yes it is. :)

    Best Regards,

    Max

Reply Children
No Data