simple push

[Carsten Rønne]

Hi, when authenticating via simple push, we often gets windows vpn showing:

The connection was prevented because of a policy on your RAS/VPN server. Specifically the authentication method used by the server to verify your user name and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error. 

Then i wait minutes and then it ussually succeeds, if not i need to put phone in flight mode, some time also coputer, and back then it works. Whats can be issue here.

MS 2025

WebADM Enterprise Edition v2.4.11-1
MFA Authentication Server: Ok (v2.2.30-1)

waproxy-1.1.28-1.x86_64

[Yoann Traut (RCDevs)]

Hello,

If I understand correctly, your issue is as follows:

You are authenticating on the Windows machine using the RCDevs Credential Provider, and then the VPN should automatically connect by reusing the credentials from the Windows session. Is that correct?

Could you clarify the following:

• Which version of the Credential Provider is running on your Windows clients?

• In which format is the username provided? For example: Username, DOMAIN\Username, or us...@domain.com?

Regards

[carsten...@alipescapital.com]

Hi,

 

I connect via Microsoft win 11 vpn like described with ldap username – no domain\ or no @domain

 

Carsten Rønne

--
You received this message because you are subscribed to the Google Groups "RCDevs Security" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rcdevs-technic...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/8faf1651-7785-4618-89a6-3795bce08155n%40googlegroups.com.

[Yoann Traut (RCDevs)]

So our Credential Provider is not involved in opening the Windows session, correct?

How is your Windows VPN integrated with our solution? Through RADIUS, I assume?

[Yoann Traut (RCDevs)]

Ok.

When it fails on the Windows side, does the authentication request reach the WebADM/OpenOTP server?

Regards

Le jeudi 20 novembre 2025 à 14:18:36 UTC+1, carsten...@alipescapital.com a écrit :

Yes, ms vpn – AD server with NPS – webadm -

 

Carsten Rønne – Sysadmin TeamLead

Alipes Capital ApS

Orientkaj 4, 1. 2150 Nordhavn

t: +45  8870 9016

www.alipes.dk

 

To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/6e7048c0-0cd2-44df-870a-06aee8cdfac0n%40googlegroups.com.

[Yoann Traut (RCDevs)]

This looks like an OpenOTP session ID, but we do not have access to your logs, so I cannot check this on your behalf :)

If the session ID is 2C3N9AE9, please provide the output of the following command:

cat /opt/webadm/logs/webadm.log | grep 2C3N9AE9 -A 50 -B 50

I need the logs immediately before and after the failure on the Windows side to understand what happens on the backend.

It is possible that short NPS RADIUS timeouts trigger request retries, and OpenOTP then rejects them because the account is already in a transaction. This typically produces a log entry such as:

User under transaction (retrying user lock in 1 second)

Do you see this in your logs for authentications originating from NPS?

Regards

Le jeudi 20 novembre 2025 à 15:37:49 UTC+1, carsten...@alipescapital.com a écrit :

Or 2C3N9AE9

--
You received this message because you are subscribed to a topic in the Google Groups "RCDevs Security" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rcdevs-technical/74hfzBKnWQ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rcdevs-technic...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/9edba937-6289-4c8b-9a76-c3e0fd311b85n%40googlegroups.com.

[carsten...@alipescapital.com]

Nps timeout is after 70 sec. webadm timeout is 60 sec.

To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/f6b346b1-7168-4e29-b167-f0df6718c55bn%40googlegroups.com.

[Yoann Traut (RCDevs)]

Ok, thank you for this info. 

What about logs that I requested ? 

Regards

[Carsten Rønne]

I will setup a test Monday to capture the logs you requested 

Thank you 

 

With kind regards

 

Carsten Rønne | System Administrator

Alipes ApS | www.alipes.dk

Vimmelskaftet 43, 2.

DK-1161 Copenhagen K.

t: +45 8870 7858

m: +45 2554 6666

 

Den 21. nov. 2025 kl. 14.56 skrev 'Yoann Traut (RCDevs)' via RCDevs Security <rcdevs-t...@googlegroups.com>:

Ok, thank you for this info. 

To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/bc7da75d-998a-4820-a2ef-e8bcdb375bc5n%40googlegroups.com.

[Spyridon Gouliarmis (RCDevs)]

I've deleted your last message with the logs, so that details of your infrastructure and employee roster don't get crawled by robots.

Can you check earlier in the same logs, if there was perhaps already one attempt, or many, by the same user to log in?

If the system had already sent a push notification a dozen seconds ago, for example, and did not yet get an answer, it would indeed refuse a new attempt so soon, outputting the logs you saw.

[carsten...@alipescapital.com]

Hi,

 

This was the first attempt today.

We have a little luck when syncing the token time from the app to start with. So perhaps this is some to do with the time.

 

Carsten Rønne – Sysadmin TeamLead

Alipes Capital ApS

Orientkaj 4, 1. 2150 Nordhavn

t: +45  8870 9016

www.alipes.dk

 

 

To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/7c7876bb-cc5e-48dd-bd63-1d9683e2c25fn%40googlegroups.com.

[carsten...@alipescapital.com]

This was the first attempt today.

We have a little luck when syncing the token time from the app to start with. So perhaps this is some to do with the time.

 

 

seems it send 2:
New openotpSimpleLogin SOAP request

New openotpSimpleLogin SOAP request

 

 

Carsten Rønne – Sysadmin TeamLead

Alipes Capital ApS

Orientkaj 4, 1. 2150 Nordhavn

t: +45  8870 9016

www.alipes.dk

 

 

From: 'Spyridon Gouliarmis (RCDevs)' via RCDevs Security <rcdevs-t...@googlegroups.com>

Sent: 25. november 2025 10:26

To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/7c7876bb-cc5e-48dd-bd63-1d9683e2c25fn%40googlegroups.com.

[Carsten Rønne]

Time was correct and latency / out of sync is very low. 

Can you help with why two simple requests are sent? 

 

With kind regards

 

Carsten Rønne | System Administrator

Alipes ApS | www.alipes.dk

Vimmelskaftet 43, 2.

DK-1161 Copenhagen K.

t: +45 8870 7858

m: +45 2554 6666

 

Den 25. nov. 2025 kl. 15.28 skrev carsten...@alipescapital.com:



This was the first attempt today.

We have a little luck when syncing the token time from the app to start with. So perhaps this is some to do with the time.

 

 

seems it send 2:
New openotpSimpleLogin SOAP request

New openotpSimpleLogin SOAP request

 

 

Carsten Rønne – Sysadmin TeamLead

Alipes Capital ApS

Orientkaj 4, 1. 2150 Nordhavn

t: +45  8870 9016

www.alipes.dk

 

To view this discussion visit https://groups.google.com/d/msgid/rcdevs-technical/031e01dc5e0d%24f3ba2240%24db2e66c0%24%40alipescapital.com.

[Carsten Rønne]

Hi, anyone who can help with this? 

 

With kind regards

 

Carsten Rønne | System Administrator

Alipes ApS | www.alipes.dk

Vimmelskaftet 43, 2.

DK-1161 Copenhagen K.

t: +45 8870 7858

m: +45 2554 6666

 

Den 26. nov. 2025 kl. 18.30 skrev Carsten Rønne <carsten...@alipescapital.com>:

Time was correct and latency / out of sync is very low. 

[Spyridon Gouliarmis (RCDevs)]

Without the exact timing, difficult to say. If the two openotpSimpleLogin requests come with a little more than 30 seconds between them, then perhaps Windows considers that our credential provider has timed out (by default, it waits 30 seconds) and re-executes it with the same inputs. The fix here is a mix of setting Token Expiration Time to 30 (the default, perhaps you changed it) in OpenOTP's settings, or telling Windows to wait longer (that's a registry value that needs changing, I believe Yoann mentioned it somewhere).

Or the two requests comme in very quick succession (1 second apart, difficult for a human to do), at which point I'd check with tcpdump whether two requests do come through on port 8443, or just one (the problem being then CP-side or WebADM-side, respectively).