How To: Check for Enrolled Users in Passcode/Authenticate Application

Follow
    Applies to:
Deployment model:
  • On Premises
  • Version Affected: All

     

    Overview

    This article explains how to check which users have enrolled for the SecureAuth Passcode or Authenticate mobile app. A quick way to check is the Audit Log for Realm998, which shows successful enrollments, but this doesn't scale well for a large number of users. This article instead shows how to query Active Directory (AD) directly with PowerShell for a complete list.

     

    Query Active Directory for Enrolled Users

    1. On your Domain Controller, open the Active Directory Module for Windows PowerShell from Administrative Tools.

    Windows Server Administrative Tools list with Active Directory Module for Windows PowerShell highlighted, and an empty PowerShell console open in the background.

    1. Run the following command, using whichever AD attribute your realm is configured to write the OATH Seed to — for example, postalAddress:
    Get-ADUser -Filter * -Properties * | ? {$_.postalAddress -ne $null} | Select-Object CN,SamAccountName,postalAddress

    PowerShell console with the Get-ADUser command typed in, ready to run.

    1. Press Enter to run the command. The output lists every AD user who has a value in that attribute — in this case, every user who has completed enrollment.

    PowerShell console showing the command's output: a table of CN, SamAccountName, and postalAddress values for several enrolled users.

    This same command works for any AD attribute, not just the one tied to OATH Seed enrollment — replace postalAddress in both places in the command with the attribute you want to check, to list every user who has a value populated in it.

     

    SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.

    Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.

    0 out of 0 found this helpful

    Comments

    0 comments

    Please sign in to leave a comment.