none
Quest ActiveRoles: Help finding accounts with blank property value

    Question

  • Hello All,

    I've been tasked with gathering the Dial-In/VPN status information on all of my companies accounts. Right now I have scripts setup using Quest ActiveRoles that will allow me to pull users with a value of TRUE and of FALSE for the msNPControlDialIn Object Attribute. However, I can't figure out how to pull the users that have a blank value for the property (Controlled through Remote Access Policy).

    Below are the scripts I've been running. Please let me know where I'm flubbing up.

    Get VPN Enabled:

    Get-QAduser -ObjectAttributes @{msNPControlDialin=$true} | Select-Object name, logonname, accountisdisabled | Export-csv "C:\TEMP\VPNUsersTRUE.csv"

    Get VPN Disabled:

    Get-QAduser -ObjectAttributes @{msNPControlDialin=$false} | Select-Object name, logonname, accountisdisabled | Export-csv "C:\TEMP\VPNUsersFALSE.csv"

    Get VPN managed by RAP:

    Get-QAduser -ObjectAttributes {$_.msNPControlDialin -ne $true} {$_.msNPControlDialin -ne $false} {$_.accountisdisabled -eq $false} | Select-Object name, logonname, accountisdisabled | Export-csv "C:\TEMP\VPNUsersRAP.csv"

    Any and all help is greatly appreciated.

    Sincerely,

    Pat M.


    • Edited by McGuinty Thursday, April 12, 2012 5:29 PM Misspell of Vender (Quest) in header. Changed so users can search for this properly.
    Tuesday, April 10, 2012 10:17 PM

Answers

  • Here are the correct filter syntaxes for using the objectAttributes query filter.  The attribute in question is either blank, Tue or False and can be tested withteh stock '' and '*' for blank and 'has a value'.   blank and False are equivalent in Quest and in AD.  Quest also allows for $true and  $false and will convert that correctly.  Attributes can be combined in any manner of complex logic to provede required filtering.

    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=$false}
    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=$true}
    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=''}
    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin='*'}

    Note that 'objectAttributes' is an alias for 'SearchAttributes'. Use that for getting help on syntax.  It is an array of tests or match pairs in the form of name=value.

    LDAP filter syntax (-LdapFilter) is more powerful and more flexible.  Both are faster than using a PowerShell filter.  You may have to retrieve 10,000 records to filter out 10.  With servereside filters this will not happen and it will be much, much faster.


    ¯\_(ツ)_/¯

    • Marked as answer by McGuinty Thursday, April 12, 2012 5:22 PM
    Thursday, April 12, 2012 5:13 PM

All replies

  • Bad logic copied from where?

    Get-QAduser -ObjectAttributes {
         msNPControlDialin -ne $true
       -AND msNPControlDialin -ne $false
       -AND accountisdisabled -eq $false
       }


    ¯\_(ツ)_/¯

    Tuesday, April 10, 2012 11:44 PM
  • JRV,

    This was actually my own doing. I'm still very new to shell scripting and thought the above quoted segment would act as a filter, effectively removing all users with the TRUE and FALSE property values for msNPControlDialin (possibly should say msNPAllowDialin?), returning only users with an empty property value and that their account was active.

    Any advice on correcting my mistake(s)? Thank you in advance to anyone for any help you can provide.

    Sincerely,

    Pat M.

    Wednesday, April 11, 2012 2:26 AM
  • Yes I know - I posted the correction.  You need to use logic to connect the components.  YOu cannot just list them one after the other.  I posted the correction.


    ¯\_(ツ)_/¯

    Wednesday, April 11, 2012 4:51 AM
  • JRV,

    Wow, I completely overlooked the -AND in your initial post. I actually had another option cross my mind while I was sleeping last night (gotta love when that happens).

    Get-QAduser | Select-Object name, logonname, msNPAllowDialin, accountisdisabled | Export-csv "C:\TEMP\VPNUsersTRUE.csv"

    That way I'll get all user accounts, can filter down to the active accounts, and then can filter as needed between the TRUE, FALSE, and (NULL?) values for the VPN property. Not sure if it will work, but we'll see. Either way, I'll be running both scripts. Thank you so much for your help.

    Sincerely,

    Pat M.

    Wednesday, April 11, 2012 11:35 AM
  • JRV,

    It looks like the script adjustment still seems to export all users regardless of their VPN setting status. Also, the above script where I added the msNPAllowDialin seems to export, but leaves that field blank for all users. This shows as being a valid property in past exports, any thoughts on who it returns blank?

    I tried to narrow down the returned fields using the below script to include -IncludedProperties so it only had name, logonname, msNPAllowDialin, and accountisdisabled, but doing so doesn't filter the export to only include these properties.

    Get-QAduser -sizelimit 0 -IncludedProperties name, logonname, msNPAllowDialin, accountisdisabled | Export-csv "C:\TEMP\VPNUsersALL.csv"

    As I'm new to this, I'm guessing my syntax is off, or I'm completely misusing the command. As an alternative I could pull all properties for all users and then filter, but I'm trying to do this so we can isolate searches by specific properties in the future.

    Thank you again for your assistance.

    Sincerely,

    Pat M.

    Wednesday, April 11, 2012 1:24 PM
  • Though JRV's suggest still allows export of user data, it would not allow me isolate by specific value of a property or just by a property in general. I was able to create the below script to allow for this.

    Get-QADUser -sizelimit 0 -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=$blank} | Select-Object Name, LogonName, msNPAllowDialin, AccountisDisabled | Export-csv "C:\TEMP\VPN_Blank.csv"

    This allows me to call all user accounts and only receive back the user's name (LastName, FirstName), LogonName, Account Disabled status, and it only filters to user's with a blank VPN (msNPAllowDialin) property value. This can be changed to TRUE or FALSE to filter accordingly.

    As I'm still new to scripting there may be some redundancy in there, but I found that if I don't include the IncludedProperties switch, some of the properties will not return their values.

    Hope this helps someone.

    Sincerely,

    Pat M.

    Thursday, April 12, 2012 4:10 PM
  • Here are the correct filter syntaxes for using the objectAttributes query filter.  The attribute in question is either blank, Tue or False and can be tested withteh stock '' and '*' for blank and 'has a value'.   blank and False are equivalent in Quest and in AD.  Quest also allows for $true and  $false and will convert that correctly.  Attributes can be combined in any manner of complex logic to provede required filtering.

    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=$false}
    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=$true}
    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin=''}
    Get-QADUser -IncludedProperties Name, LogonName, msNPAllowDialin -ObjectAttributes @{msNPAllowDialin='*'}

    Note that 'objectAttributes' is an alias for 'SearchAttributes'. Use that for getting help on syntax.  It is an array of tests or match pairs in the form of name=value.

    LDAP filter syntax (-LdapFilter) is more powerful and more flexible.  Both are faster than using a PowerShell filter.  You may have to retrieve 10,000 records to filter out 10.  With servereside filters this will not happen and it will be much, much faster.


    ¯\_(ツ)_/¯

    • Marked as answer by McGuinty Thursday, April 12, 2012 5:22 PM
    Thursday, April 12, 2012 5:13 PM
  • JRV,

    Thank you for the clarification. I'll keep this in mind when building future scripts. Now I get to read up on the additional switches you provided. :-)

    Sincerely,

    Pat M.

    Thursday, April 12, 2012 5:22 PM