Strange Login Issue

[jonchill]

Up until the begining of this week our Pulse VM and clients have been working perfectly but since Monday we've been getting odd reports from the users saying they are getting 1319 error messages when they try and login but if they try a number of times it will eventually allow access.

In the user logs I'm seeing lots of these error messages for multiple different users

AUT24327 2019-02-08 15:18:41 - ive - [92.9.206.238] Default Network::LSS\sharonrow(Managed)[] - Primary authentication failed for LSS\xxxxxxxxx/LSS-AD from 92.9.206.238

And I'm also seeing in the Admin logs lots of these errors.

ADM22862 2019-02-08 15:44:58 - ive - [127.0.0.1] Default Network::System()[] - User Accounts modified. Removed username LSS\xxxxx from authentication server LSS-AD.

My first instict is that its a backend AD issue but just wanted to run it past the experts to make sure that it is actually an AD auth issue rather than a Pulse issue.

Any help or advice would be much appreciated.

Thanks

Jon

[[email protected]]

Hi Jon,

Primary authentication failed is a generic error message

[1319]

Short-desc = Authentication rejected by server.

Long-desc = Try the operation again. If the problem persists, contact your network administrator.

which could be caused by any of these reason(s),

1) Communication issue between the VPN and AD - No network connectivity.

2) Incorrect credentials are used during login.

3) A very rare possibility of AD services malfunction.

Do you see any auth server unreachable messages got generated under the Event logs during that time period? or any events related to AD authentication?

Thanks,
Ray.

[jonchill]

Ray

We're not seeing auth unreachable messages in the Events log and the AD admin have come back to us to say that they aren't seeing any issue with the AD servers.

One thing we have noticed is that the connections that are having issues in the user logs have this message the below message

AUT24803 2019-02-12 10:18:35 - ive - [213.205.192.30] Root::HayleySm(unknown)[] - Host Checker policy 'Community Host Check' passed on host '213.205.192.30' address 'a4-34-d9-e8-2c-18' for user 'HayleySm'.

Whereas the message below is what a successful connection shows

AUT24803 2019-02-12 10:18:31 - ive - [127.0.0.1] Root::LSS\nicolabos(Managed)[] - Host Checker policy 'Community Host Check' passed on host '176.254.190.171' address '90-61-ae-d5-e0-1c' for user 'LSS\nicolabos'.

Thanks

Jon

[[email protected]]

Hi Jon,

Both logs are showing the host checker compliance results (pass for both users). Any other messages got generated for the failed users?

Thanks,

Ray.

[zanyterp]

how many servers do you have in your server farm? i agree that it looks to be an issue with either replication between domain controllers or communication between the PCS & AD.

[jonchill]

Yesterday I logged a call with Pulse support and after sending logs and traces etc got a response from them this morning (below) and its looking like a Pulse client issue, hopefully the latest client will resolve the issue but I'm still not sure why all of a sudden all of our Windows 7 laptops over the course of a week got this exact same issue, interestingly up until now our Windows 10 laptops with the same client aren't having the same issue. My only thought is that the Jan MS updates we're rolled out first week of Feb and whether for some reason one of these patches triggered an issue in the client.

I have verified the given logs and confirmed the below events, when the Authentication is getting failed. Initial connectivity to the PCS device is established, and the Certificate on the user machine is also found, however post then we are getting "Processing EAP-Failure"

00167,09 2019/02/13 14:34:49.220 3 SYSTEM PulseSecureService.exe eapService p2184 t1F28 EapService.cpp:70 - 'eapService' Processing EAP-Failure: code = 4, id = 15, length = 4

00186,09 2019/02/13 14:34:49.220 1 SYSTEM PulseSecureService.exe iftProvider p2184 t1028 channelProviderImplEap.cpp:410 - 'iftProvider' EAP Authentication FAILED: Error: 1319 0x527 State: 3 0x3

00151,09 2019/02/13 14:34:49.220 1 SYSTEM PulseSecureService.exe iftProvider p2184 t1028 channelProviderImplEap.cpp:432 - 'iftProvider' Eap failed 1319 0x527

Since it is Realm level restriction which is failed, so the Policy trace doesn't capture the informations.

I would suggested you to test by installing the latest Pulse Client version 5.3R7 or 9.0R3 on any of the affected machine and confirm the behavior

[zanyterp]

Thank you for the update and opening a ticket with support.
if you are using both certificate & AD, that looks like the AD component is failing

[scarlett]

I am experiencing the same issues - I connect remotely from both PC and Mac and get the 1319 error since beginning of september. My customer (the one providing me with Pulse Secure Client) want to upgrade my PC system to Win 10 - will it solve the issue on the PC?
And what to do on my Mac?

[scarlett]

On the Mac I just installed latest version of the client  9.0.4 (1731). Still same error: 1319.
On the PC I have to wait for support to reinstall current version 9.0.3 - but I guess THAT will not do the trick. Suggestions on how to proceed?

[marcrp]

We too have been experiencing this authentication issue since beginning of September. We have a range of client versions from 5.3.7 to 9.0 and all of them experience the issue randomly. 

We also have 2 Pulse Secure servers and both of them experience the issue when authenticating against them.

We are due to upgrade to PCS 9.1 next week so I'll see if that helps.