DUO Phishing Question

147 views
Skip to first unread message

Ken Dibble

unread,
Sep 29, 2023, 11:27:47 AM9/29/23
to ntsys...@googlegroups.com
I realize this is off-topic, but:

Is there any known way by which a DUO user can receive a bogus push
notification without someone having that person's login credentials
for the system using DUO?

Are there any known instances in which a spoofed DUO push contains
the option to report the push as fraudulent, and then an
apparently-legitimate DUO fraud report is issued to us?

Thanks.

Ken Dibble
www.stic-cil.org

Kurt Buff

unread,
Sep 29, 2023, 1:23:47 PM9/29/23
to ntsys...@googlegroups.com
We use Duo.

I'm not aware of any fraudulent pushes. OTOH, if a user declines the push, perhaps by mistake, a notification is generated to someone (the user, or a Duo admin? I can't remember).

However, if the account ID/password has been compromised, then attempts by the malefactor to log in will generate pushes, and if the victim approves the notification then the intrusion is successful.

Kurt

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6516ecf1.4a0a0220.a70ef.ee4fSMTPIN_ADDED_MISSING%40gmr-mx.google.com.

CR Hiestand

unread,
Sep 29, 2023, 1:28:43 PM9/29/23
to ntsys...@googlegroups.com
If you are using Duo for Windows with RDP and the device doing RDP goes to sleep, sometimes when it wakes back up it will reconnect RDP in the background and trigger Duo (it’s not an acronym) which may be interpreted as an unexpected prompt. 

Admins can also trigger pushes from the admin site. But generally no the pushes are legitimate indicating the associated user attempted to access a Duo protected service. 

Sent from Gmail Mobile


Ken Dibble

unread,
Sep 29, 2023, 1:34:20 PM9/29/23
to ntsys...@googlegroups.com
Yes. In our particular case a user got a push without actually having tried to log into something. I can think of a couple of scenarios where this can occur, but as far as I can tell, I can't see any way it could occur unless somebody had her correct credentials, because AD LDAP primary authentication must be successful first, before the DUO proxy issues a push.

We've changed the PWD, of course, but for due diligence purposes I'd like to know if there is any way this event could have been triggered without someone or something having those creds. But, see my response to CR Hiestand.

Thanks,

Ken Dibble
www.stic-cil.org

At 01:23 PM 9/29/2023, Kurt Buff wrote:
We use Duo.

I'm not aware of any fraudulent pushes. OTOH, if a user declines the push, perhaps by mistake, a notification is generated to someone (the user, or a Duo admin? I can't remember).

However, if the account ID/password has been compromised, then attempts by the malefactor to log in will generate pushes, and if the victim approves the notification then the intrusion is successful.

Kurt

On Fri, Sep 29, 2023 at 9:27 AM Ken Dibble <ke...@stic-cil.org> wrote:
I realize this is off-topic, but:

Is there any known way by which a DUO user can receive a bogus push
notification without someone having that person's login credentials
for the system using DUO?

Are there any known instances in which a spoofed DUO push contains
the option to report the push as fraudulent, and then an
apparently-legitimate DUO fraud report is issued to us?

Thanks.

Ken Dibble
www.stic-cil.org

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6516ecf1.4a0a0220.a70ef.ee4fSMTPIN_ADDED_MISSING%40gmr-mx.google.com .

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Ken Dibble

unread,
Sep 29, 2023, 1:38:57 PM9/29/23
to ntsys...@googlegroups.com
This might be relevant. In our case we're using an SSL VPN, to which the user must login successfully before they can get to the RDP server. However, the event I'm describing occurred rather late at night, so this could be a "sleep" scenario.

The question then becomes, is the VPN capable of caching the creds and requesting a login on its own without user intervention? The VPN dialog offers the option of saving credentials, but we've been EXTREMELY clear that NO ONE should ever tell it to do that. Can it do it anyway if the user didn't specifically authorize saving credentials?

Thanks.

Ken Dibble
www.stic-cil.org

At 01:28 PM 9/29/2023, CR Hiestand wrote:
If you are using Duo for Windows with RDP and the device doing RDP goes to sleep, sometimes when it wakes back up it will reconnect RDP in the background and trigger Duo (it's not an acronym) which may be interpreted as an unexpected prompt.

Admins can also trigger pushes from the admin site. But generally no the pushes are legitimate indicating the associated user attempted to access a Duo protected service.

Sent from Gmail Mobile


On Fri, Sep 29, 2023 at 11:27 AM Ken Dibble <ke...@stic-cil.org> wrote:
I realize this is off-topic, but:

Is there any known way by which a DUO user can receive a bogus push
notification without someone having that person's login credentials
for the system using DUO?

Are there any known instances in which a spoofed DUO push contains
the option to report the push as fraudulent, and then an
apparently-legitimate DUO fraud report is issued to us?

Thanks.

Ken Dibble
www.stic-cil.org

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/6516ecf1.4a0a0220.a70ef.ee4fSMTPIN_ADDED_MISSING%40gmr-mx.google.com .

--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Ken Dibble

unread,
Sep 29, 2023, 1:51:58 PM9/29/23
to ntsys...@googlegroups.com
The VPN is set to disconnect after a period of inactivity, but as far as I know it's not configured to try to reconnect on its own. It might pop-up the login dialog at that point... we're doing some tests.

Ken

CR Hiestand

unread,
Sep 29, 2023, 1:53:18 PM9/29/23
to ntsys...@googlegroups.com
Do you have magical users that actually read and follow instructions? 

Sent from Gmail Mobile


--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Ken Dibble

unread,
Sep 29, 2023, 1:56:39 PM9/29/23
to ntsys...@googlegroups.com
Yeah, I know, and since we changed the PWD we can't jump into her laptop and test whether the thing would try to connect without manual entry of the creds now. I really wanted a VPN client that either doesn't offer the option to save creds at all, or that can be centrally configured not to do that, but this one doesn't have that capability.

Thanks.

Ken


At 01:53 PM 9/29/2023, CR Hiestand wrote:
Do you have magical users that actually read and follow instructions?

Sent from Gmail Mobile


--

Erno, Cynthia M (ITS)

unread,
Oct 2, 2023, 3:07:50 AM10/2/23
to ntsys...@googlegroups.com

ROFL

 

Cynthia Erno

 

 

From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of CR Hiestand
Sent: Friday, September 29, 2023 1:53 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] DUO Phishing Question

 

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.

 

Ken Dibble

unread,
Oct 2, 2023, 12:09:13 PM10/2/23
to ntsys...@googlegroups.com
Yeah, I find the concept of zombie laptops butt-dialing Duo in the middle of the night pretty funny too.

So, an update on this:

Testing showed that the VPN caches the credentials regardless of whether the user checks the "save my information" box or not. Computer goes to sleep, disconnecting the internet while the VPN is connected. Computer decides to wake itself up for some reason (we've seen that before), which results in the internet connection being restored (either via LAN cable or because the user told Windows to automatically connect to some WAP). That triggers the VPN to use its stored credentials to reconnect, meaning it submits them through the Duo proxy server, gets them okayed by the LDAP server, after which the proxy calls Duo to send a push.

So another "magical" solution would be to tell users to make sure to disconnect the VPN before going away from the computer. Compliance there would be about the same.... Though I suppose getting woken up in the middle of the night by a push on your phone might motivate you.

We have the idle-peer disconnection time set pretty high so we can remotely install CUs to unattended machines. I don't really want to cut that time down by much. We're still looking into whether we can configure the VPN not to auto-reconnect; might be possible by means of an obscure route involving uploads of what look like JSON files.

Jeez, I just love 2FA....

Thanks.

Ken Dibble
www.stic-cil.org




--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Ken Dibble

unread,
Oct 2, 2023, 1:39:07 PM10/2/23
to ntsys...@googlegroups.com
In the instance under discussion, we have now learned:

The laptop was in our office, connected by LAN cable to our network, and turned off. (We don't enable wake-on-LAN here.) The user got a Duo push on her phone while at home at around 11:30 pm. There are only two ways to activate our Duo: 1) Log into the domain-user specific installation of the VPN client on the computer 2) Log into the VPN user portal on our router. In both cases, the user must submit the correct domain user credentials, and have them accepted by the DC, before Duo will send a push.

The user got an official-looking Duo push on the phone, which had an option for her to report a fraudulent attempt, which she did. We then got an email, apparently from actual Duo, almost immediately reporting that attempt.

Assuming that the user did not share her credentials with anyone else intentionally, how could this have happened?

One way would be if she violated our rules and applied a password to her domain user account that she had previously used for some other purpose--for which the credentials were stolen. Then we would expect to see an attempt to log into the router user portal at around 11:30 pm, but the logs showed no such attempt.

We will check the logs on the laptop to see if it was running when she thought it was shut down. In the meantime, can anyone suggest ANY other explanation for these facts?

Thanks.

Ken Dibble
www.stic-cil.org

Mike

unread,
Oct 2, 2023, 1:49:41 PM10/2/23
to ntsys...@googlegroups.com
What do the Duo logs in their admin portal show? They should show you the date/time, Duo protected app used, and the source IP among other things.

Ken Dibble

unread,
Oct 2, 2023, 2:08:09 PM10/2/23
to ntsys...@googlegroups.com
The logs never have an IP address; they all show 0.0.0.0 regardless of whether the 2nd factor is accepted or not. Sometimes the "Authentication Method" column will give a location, such as: "Duo Push Binghamton NY United States" (which is where we are). Sometimes they say "Duo Push location unknown". In this case, for this user, there were two logged events, about 3 minutes apart.

The first was "Denied - no response" with "Location unknown".

The second was "Denied - user marked fraud" with "Location Binghamton NY United States".

What location is referenced by these logs? The location of the phone receiving the push? The location of the sending server (seems likely since we have locations in the logs from other cities in New York where our employees never go)? The location of the process that attempted to log into the Duo-managed interface?

Thanks.

Ken Dibble
www.stic-cil.org


At 01:49 PM 10/2/2023, Mike wrote:
What do the Duo logs in their admin portal show? They should show you the date/time, Duo protected app used, and the source IP among other things.

On Mon, Oct 2, 2023 at 1:39 PM Ken Dibble <ke...@stic-cil.org> wrote:
In the instance under discussion, we have now learned:

The laptop was in our office, connected by LAN cable to our network, and turned off. (We don't enable wake-on-LAN here.) The user got a Duo push on her phone while at home at around 11:30 pm. There are only two ways to activate our Duo: 1) Log into the domain-user specific installation of the VPN client on the computer 2) Log into the VPN user portal on our router. In both cases, the user must submit the correct domain user credentials, and have them accepted by the DC, before Duo will send a push.

The user got an official-looking Duo push on the phone, which had an option for her to report a fraudulent attempt, which she did. We then got an email, apparently from actual Duo, almost immediately reporting that attempt.

Assuming that the user did not share her credentials with anyone else intentionally, how could this have happened?

One way would be if she violated our rules and applied a password to her domain user account that she had previously used for some other purpose--for which the credentials were stolen. Then we would expect to see an attempt to log into the router user portal at around 11:30 pm, but the logs showed no such attempt.

We will check the logs on the laptop to see if it was running when she thought it was shut down. In the meantime, can anyone suggest ANY other explanation for these facts?

Thanks.

Ken Dibble
www.stic-cil.org

At 12:09 PM 10/2/2023, I wrote:
Yeah, I find the concept of zombie laptops butt-dialing Duo in the middle of the night pretty funny too.

So, an update on this:

Testing showed that the VPN caches the credentials regardless of whether the user checks the "save my information" box or not. Computer goes to sleep, disconnecting the internet while the VPN is connected. Computer decides to wake itself up for some reason (we've seen that before), which results in the internet connection being restored (either via LAN cable or because the user told Windows to automatically connect to some WAP). That triggers the VPN to use its stored credentials to reconnect, meaning it submits them through the Duo proxy server, gets them okayed by the LDAP server, after which the proxy calls Duo to send a push.

So another "magical" solution would be to tell users to make sure to disconnect the VPN before going away from the computer. Compliance there would be about the same.... Though I suppose getting woken up in the middle of the night by a push on your phone might motivate you.

We have the idle-peer disconnection time set pretty high so we can remotely install CUs to unattended machines. I don't really want to cut that time down by much. We're still looking into whether we can configure the VPN not to auto-reconnect; might be possible by means of an obscure route involving uploads of what look like JSON files.

Jeez, I just love 2FA....

Thanks.

Ken Dibble
www.stic-cil.org


At 03:07 AM 10/2/2023, Erno, Cynthia M wrote:

ROFL

Â

Cynthia Erno

Â

Â

Sent: Friday, September 29, 2023 1:53 PM
Subject: Re: [ntsysadmin] DUO Phishing Question

Â

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.

Â

Do you have magical users that actually read and follow instructions?


Sent from Gmail Mobile

Â

Â

--
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Ken Dibble

unread,
Oct 2, 2023, 2:09:58 PM10/2/23
to ntsys...@googlegroups.com
I should have added that in all cases the application is "LDAP Proxy", since it's the same server for both the VPN and the user portal.


At 02:08 PM 10/2/2023, I wrote:
The logs never have an IP address; they all show 0.0.0.0 regardless of whether the 2nd factor is accepted or not. Sometimes the "Authentication Method" column will give a location, such as: "Duo Push Binghamton NY United States" (which is where we are). Sometimes they say "Duo Push location unknown". In this case, for this user, there were two logged events, about 3 minutes apart.

The first was "Denied - no response" with "Location unknown".

The second was "Denied - user marked fraud" with "Location Binghamton NY United States".

What location is referenced by these logs? The location of the phone receiving the push? The location of the sending server (seems likely since we have locations in the logs from other cities in New York where our employees never go)? The location of the process that attempted to log into the Duo-managed interface?

Thanks.

Ken Dibble
www.stic-cil.org


At 01:49 PM 10/2/2023, Mike wrote:
What do the Duo logs in their admin portal show? They should show you the date/time, Duo protected app used, and the source IP among other things.

On Mon, Oct 2, 2023 at 1:39â€Â¯PM Ken Dibble <ke...@stic-cil.org> wrote:
In the instance under discussion, we have now learned:
The laptop was in our office, connected by LAN cable to our network, and turned off. (We don't enable wake-on-LAN here.) The user got a Duo push on her phone while at home at around 11:30 pm. There are only two ways to activate our Duo: 1) Log into the domain-user specific installation of the VPN client on the computer 2) Log into the VPN user portal on our router. In both cases, the user must submit the correct domain user credentials, and have them accepted by the DC, before Duo will send a push.
The user got an official-looking Duo push on the phone, which had an option for her to report a fraudulent attempt, which she did. We then got an email, apparently from actual Duo, almost immediately reporting that attempt.
Assuming that the user did not share her credentials with anyone else intentionally, how could this have happened?
One way would be if she violated our rules and applied a password to her domain user account that she had previously used for some other purpose--for which the credentials were stolen. Then we would expect to see an attempt to log into the router user portal at around 11:30 pm, but the logs showed no such attempt.
We will check the logs on the laptop to see if it was running when she thought it was shut down. In the meantime, can anyone suggest ANY other explanation for these facts?
Thanks.
Ken Dibble
www.stic-cil.org

At 12:09 PM 10/2/2023, I wrote:
Yeah, I find the concept of zombie laptops butt-dialing Duo in the middle of the night pretty funny too.
So, an update on this:
Testing showed that the VPN caches the credentials regardless of whether the user checks the "save my information" box or not. Computer goes to sleep, disconnecting the internet while the VPN is connected. Computer decides to wake itself up for some reason (we've seen that before), which results in the internet connection being restored (either via LAN cable or because the user told Windows to automatically connect to some WAP). That triggers the VPN to use its stored credentials to reconnect, meaning it submits them through the Duo proxy server, gets them okayed by the LDAP server, after which the proxy calls Duo to send a push.

So another "magical" solution would be to tell users to make sure to disconnect the VPN before going away from the computer. Compliance there would be about the same.... Though I suppose getting woken up in the middle of the night by a push on your phone might motivate you.
We have the idle-peer disconnection time set pretty high so we can remotely install CUs to unattended machines. I don't really want to cut that time down by much. We're still looking into whether we can configure the VPN not to auto-reconnect; might be possible by means of an obscure route involving uploads of what look like JSON files.
Jeez, I just love 2FA....
Thanks.
Ken Dibble
www.stic-cil.org

At 03:07 AM 10/2/2023, Erno, Cynthia M wrote:

ROFL
Â
Cynthia Erno
Â
Â
Sent: Friday, September 29, 2023 1:53 PM
Subject: Re: [ntsysadmin] DUO Phishing Question
Â

ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
Â
Do you have magical users that actually read and follow instructions?

Sent from Gmail Mobile
Â
Â

Mike

unread,
Oct 2, 2023, 4:13:54 PM10/2/23
to ntsys...@googlegroups.com
We usually see the IP of the user as well as the general location of that IP (based on whatever geolocation database Duo is using).
But we don't use the Duo LDAP proxy, which is why you are probably seeing 0.0.0.0 for everything.

I believe Duo has a text log file on the server that runs the proxy as well; anything interesting in there?
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/651b0707.050a0220.5d89d.11beSMTPIN_ADDED_MISSING%40gmr-mx.google.com.

CR Hiestand

unread,
Oct 2, 2023, 4:18:29 PM10/2/23
to ntsys...@googlegroups.com
It’s expected for the LDAP proxy to show no location: 
Sent from Gmail Mobile


Ken Dibble

unread,
Oct 3, 2023, 10:19:27 AM10/3/23
to ntsys...@googlegroups.com
I'm not finding a "Duo" log on the server. I don't think "Duo" itself is installed on the server; I think this is a generic RADIUS proxy server configured to talk to the Duo cloud. Research indicates that a RADIUS proxy server should have logs associated with "NPS" but I'm not finding that category in Event Viewer. and I don't know what numbers to look for.

In any event, further investigation confirms that the allegedly turned-off laptop was in fact running and likely in hibernation/sleep when the event occurred. User self-reports are just soooo illuminating (*sigh*). Turns out the user had used the password for something else as well. On the other hand, she insists that nobody else who could have been in the building would know the password. Since there's no log entry on the UTM/router/firewall indicating somebody tried to log into the user portal with those creds at that time, I don't think this was a malicious attack; it seems more likely that the "butt-dialing" theory is correct.

Ken Dibble
www.stic-cil.org

At 04:13 PM 10/2/2023, Mike wrote:
We usually see the IP of the user as well as the general location of that IP (based on whatever geolocation database Duo is using).
But we don't use the Duo LDAP proxy, which is why you are probably seeing 0.0.0.0 for everything.

I believe Duo has a text log file on the server that runs the proxy as well; anything interesting in there?

On Mon, Oct 2, 2023 at 2:08 PM Ken Dibble <ke...@stic-cil.org> wrote:
The logs never have an IP address; they all show 0.0.0.0 regardless of whether the 2nd factor is accepted or not. Sometimes the "Authentication Method" column will give a location, such as: "Duo Push Binghamton NY United States" (which is where we are). Sometimes they say "Duo Push location unknown". In this case, for this user, there were two logged events, about 3 minutes apart.

The first was "Denied - no response" with "Location unknown".

The second was "Denied - user marked fraud" with "Location Binghamton NY United States".

What location is referenced by these logs? The location of the phone receiving the push? The location of the sending server (seems likely since we have locations in the logs from other cities in New York where our employees never go)? The location of the process that attempted to log into the Duo-managed interface?

Thanks.

Ken Dibble
www.stic-cil.org


At 01:49 PM 10/2/2023, Mike wrote:
What do the Duo logs in their admin portal show? They should show you the date/time, Duo protected app used, and the source IP among other things.

On Mon, Oct 2, 2023 at 1:39â€Â¯PM Ken Dibble <ke...@stic-cil.org> wrote:
In the instance under discussion, we have now learned:
The laptop was in our office, connected by LAN cable to our network, and turned off. (We don't enable wake-on-LAN here.) The user got a Duo push on her phone while at home at around 11:30 pm. There are only two ways to activate our Duo: 1) Log into the domain-user specific installation of the VPN client on the computer 2) Log into the VPN user portal on our router. In both cases, the user must submit the correct domain user credentials, and have them accepted by the DC, before Duo will send a push.
The user got an official-looking Duo push on the phone, which had an option for her to report a fraudulent attempt, which she did. We then got an email, apparently from actual Duo, almost immediately reporting that attempt.
Assuming that the user did not share her credentials with anyone else intentionally, how could this have happened?
One way would be if she violated our rules and applied a password to her domain user account that she had previously used for some other purpose--for which the credentials were stolen. Then we would expect to see an attempt to log into the router user portal at around 11:30 pm, but the logs showed no such attempt.
We will check the logs on the laptop to see if it was running when she thought it was shut down. In the meantime, can anyone suggest ANY other explanation for these facts?
Thanks.
Ken Dibble
www.stic-cil.org

At 12:09 PM 10/2/2023, I wrote:
Yeah, I find the concept of zombie laptops butt-dialing Duo in the middle of the night pretty funny too.

So, an update on this:
Testing showed that the VPN caches the credentials regardless of whether the user checks the "save my information" box or not. Computer goes to sleep, disconnecting the internet while the VPN is connected. Computer decides to wake itself up for some reason (we've seen that before), which results in the internet connection being restored (either via LAN cable or because the user told Windows to automatically connect to some WAP). That triggers the VPN to use its stored credentials to reconnect, meaning it submits them through the Duo proxy server, gets them okayed by the LDAP server, after which the proxy calls Duo to send a push.
So another "magical" solution would be to tell users to make sure to disconnect the VPN before going away from the computer. Compliance there would be about the same.... Though I suppose getting woken up in the middle of the night by a push on your phone might motivate you.
We have the idle-peer disconnection time set pretty high so we can remotely install CUs to unattended machines. I don't really want to cut that time down by much. We're still looking into whether we can configure the VPN not to auto-reconnect; might be possible by means of an obscure route involving uploads of what look like JSON files.
Jeez, I just love 2FA....
Thanks.
Ken Dibble
www.stic-cil.org

At 03:07 AM 10/2/2023, Erno, Cynthia M wrote:

ROFL
Â
Cynthia Erno
Â
Â
Sent: Friday, September 29, 2023 1:53 PM
Subject: Re: [ntsysadmin] DUO Phishing Question
Â
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.

Â

Do you have magical users that actually read and follow instructions?


Sent from Gmail Mobile

Â

Â

--
--
--


--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.

Melvin Backus

unread,
Oct 3, 2023, 11:16:46 AM10/3/23
to ntsys...@googlegroups.com

Look at the NPS server itself and see where it’s sending logs. There are multiple options as I recall, but it’s been a few years since I’ve done one.

 

--
There are 10 kinds of people in the world...
         those who understand binary and those who don't.

 

¯\_()_/¯

Reply all
Reply to author
Forward