none
Get-AdfsAccountActivity Error PS0345 RRS feed

  • Question

  • When running the PowerShell command Get-AdfsAccountActivity <UPN>, I am getting the following error no matter what UPN I query.  (where <UPN> is the actual UserPrincipalName of the AD account)

    Get-AdfsAccountActivity : PS0345: Account <UPN> could not be located in the ADFS account database.
    At line:1 char:1
    + Get-AdfsAccountActivity -UserPrincipalName <UPN>
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : NotSpecified: (:) [Get-AdfsAccountActivity], UserActivityRestServiceException
        + FullyQualifiedErrorId : Microsoft.IdentityServer.User.UserActivityRestServiceException,Microsoft.IdentityServer.
       Management.Commands.GetAdfsAccountActivity

    I am running the command from an elevated prompt logged in as the domain administrator.  The command used to work.  As I don't use it too often though, I am unable to pinpoint when it stopped or what caused it to stop working.  The server is Windows Server 2016 (ADFS 4.0).

    Any help would be much appreciated.

    Monday, August 26, 2019 7:40 PM

All replies

  • Running into the same problem as well and I'm wondering if it's patch related.
    Wednesday, August 28, 2019 11:19 PM
  • You know, I didn't think of that.  It very may well be, because the server did just update recently.  Too bad I can't roll it back to check.
    Thursday, August 29, 2019 1:05 PM
  • Are you seeing any errors in your audit logs that coincide with your queries?

    I'm seeing this:

    The Federation Service failed to issue a valid token. See XML for failure details. 

    Activity ID: 82907636-8302-48b6-2946-0080000000ea 

    Additional Data 
    XML: <?xml version="1.0" encoding="utf-16"?>
    <AuditBase xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AppTokenAudit">
      <AuditType>AppToken</AuditType>
      <AuditResult>Failure</AuditResult>
      <FailureType>GenericError</FailureType>
      <ErrorCode>N/A</ErrorCode>
      <ContextComponents>
        <Component xsi:type="ResourceAuditComponent">
          <RelyingParty>N/A</RelyingParty>
          <ClaimsProvider>N/A</ClaimsProvider>
          <UserId>N/A</UserId>
        </Component>
        <Component xsi:type="AuthNAuditComponent">
          <PrimaryAuth>N/A</PrimaryAuth>
          <DeviceAuth>false</DeviceAuth>
          <DeviceId>N/A</DeviceId>
          <MfaPerformed>false</MfaPerformed>
          <MfaMethod>N/A</MfaMethod>
          <TokenBindingProvidedId>false</TokenBindingProvidedId>
          <TokenBindingReferredId>false</TokenBindingReferredId>
          <SsoBindingValidationLevel>NotSet</SsoBindingValidationLevel>
        </Component>
        <Component xsi:type="ProtocolAuditComponent">
          <OAuthClientId>N/A</OAuthClientId>
          <OAuthGrant>N/A</OAuthGrant>
        </Component>
        <Component xsi:type="RequestAuditComponent">
          <Server>N/A</Server>
          <AuthProtocol>N/A</AuthProtocol>
          <NetworkLocation>Intranet</NetworkLocation>
          <IpAddress>fe80::b923:414:ae1e:98cf%4</IpAddress>
          <ForwardedIpAddress />
          <ProxyIpAddress>N/A</ProxyIpAddress>
          <NetworkIpAddress>N/A</NetworkIpAddress>
          <ProxyServer>N/A</ProxyServer>
          <UserAgentString>N/A</UserAgentString>
          <Endpoint>/adfs/users/[user I'm trying to query here]</Endpoint>
        </Component>
      </ContextComponents>
    </AuditBase>

    Friday, August 30, 2019 4:43 PM
  • (Sorry for the late response)

    Yes, I'm seeing similar errors.

    Tuesday, September 3, 2019 8:41 PM
  • Hi,

    Was anyone able to resolve this error?

    Thanks

    Wednesday, September 18, 2019 3:54 PM
  • Sorry for the late response.  Not getting notifications for this thread for some reason.

    No, still haven't gotten it fixed.  Have some updates pending, so I'll check it again after the updates and see what happens.

    Edit:  Updates did not resolve the issue.  Will have to troubleshoot more.
    • Edited by Allen Hudson Wednesday, October 2, 2019 1:58 PM New information
    Wednesday, October 2, 2019 1:15 PM
  • UPDATE!!!

    I have discovered that if I execute Reset-ADFSAccountLockout against a user's account using either the Familiar or Unknown locations, the records for that user are once again searchable (although now reset).  I still get the error when trying to query a user that hasn't been reset.  This leads me to believe this could be a database related issue.

    EDIT:  Hmm, seems that though I can see a user's record, it isn't being written to on bad password attempts.  I am able to set Familiar IP addresses, but no amount of typing the password incorrectly gets recorded.  They are showing up in the event log though.  More investigating...
    Friday, October 4, 2019 3:18 PM
  • Hi,

    Do you have an update?
    We are having the same issue. I can query existing accounts with "Get-AdfsAccountActivity <UPN>" then I get a normal result. When I query a newly created account I'm getting the same error message as you.

    Thanks

    Thursday, October 10, 2019 7:02 AM
  • Did you find the fix? I am experiencing the same issue, and it seems to have occurred after patching the ADFS server. 
    Thursday, October 17, 2019 8:46 PM
  • Could this have something to do with the KB4519979 update, specifically where it says:

    "Addresses an intermittent issue in Active Directory Federation Services (AD FS) that fails to authenticate users. Additionally, AD FS redirects the browser back to the Microsoft Exchange Client Access services (CAS) with the wrong Audience uniform resource identifier (URI). Specifically, AD FS appends a slash to the Audience URI. Users see an error page and cannot access the Outlook Web App (OWA)." 


    Thursday, October 17, 2019 8:55 PM
  • We're also experiencing this issue. 

    The reset flag does indeed allow us to see results, however as stated above no number of bad passwords for the account appear to be updating the fields. 

    What's worse than that is that there are two entries for the account. one listed in the USERID table as DOMAIN\username and the other as the UPN username@domain. The entries listed in the USERID table do have bad password attempts listed for the DOMAIN\username entries (at least most of them do). 

    We've also established that the database hasn't been updated in almost a week. It's running, the services are all working as expected (except ExLO), but the database tables show a last updated time of the Oct 19.

    Wednesday, October 30, 2019 6:57 PM
  • Hi,

    Do you have an update?
    We are having the same issue. I can query existing accounts with "Get-AdfsAccountActivity <UPN>" then I get a normal result. When I query a newly created account I'm getting the same error message as you.

    Thanks

    Sorry for such a late response.  No, we are still experiencing the same issue and I haven't had the time to further troubleshoot yet.
    Wednesday, November 6, 2019 3:47 PM
  • Could this have something to do with the KB4519979 update, specifically where it says:

    "Addresses an intermittent issue in Active Directory Federation Services (AD FS) that fails to authenticate users. Additionally, AD FS redirects the browser back to the Microsoft Exchange Client Access services (CAS) with the wrong Audience uniform resource identifier (URI). Specifically, AD FS appends a slash to the Audience URI. Users see an error page and cannot access the Outlook Web App (OWA)." 


    At this point, anything is possible.  I doubt it's that exact issue though, because our users aren't receiving error pages and aren't locked out of any services.
    Wednesday, November 6, 2019 3:47 PM
  • Here's a new thought... could this be caused by not having WAP configured?
    Thursday, November 7, 2019 2:49 PM