Kaseya Community

User account and environment audit

  • Providing a bit of a back story to the question at hand. My office has a client who within the past year had to downsize rather dramatically from roughly 250 employees down to about 40 over a 6 month period. During that time frame we were actively disabling all AD, Email and other related accounts during each employees off-boarding date. However as time went on the client started having issues with being able to access accounts due to 3-party Org. being tied to a terminated employees email account, or AD accounts being used by other employees which we were not aware of and neither was our client. The client had multiple sites with 1-3 computers, but several employees coming to a site and would not use there own accounts, but rather rely on what was logged in at the time. The onsite IT that was employed by this client allowed this to happen before we were brought on.

    All though the email side of this problem has been resolved, we have the AD side of the situation to resolve and sadly it is not as simple as ensuring that terminated employee A's AD is terminated so that current employee B is not not using it. We've even found some that were using a local account that was in place prior to our office taking on this client (again, on site IT).

    So my question is this, is anyone aware of a procedure or script that can be ran in Kaseya that will prompt the logged in user with A: The name of the machine/Kaseya agent they are using, B: Report the account name that they are logged in with & C: If possible determine if it is a local or AD account? The plan is to have that employee report back to an on site contact with that information so that we can proceed with additional steps that have to be taken.

    Any assistance with this would be greatly appreciated & I thank you for your time in advance.

  • Don't know if this would help, but you could create a custom field in audit>View individual data>Machine summary. Name it something like FullUserName.

    Then, create a powershell script (Just a text file named xxx.ps1). Here is what mine contains:

    $fulluser= Get-WmiObject -Class Win32_UserProfile | Select-Object -Property SID,LocalPath,Loaded,LastUseTime,@{Name="Account";Expression={((New-Object -TypeName System.Security.Principal.SecurityIdentifier($_.SID)).Translate([System.Security.Principal.NTAccount])).Value}} | Where-Object {$_.LocalPath -like "C:\Users*"} | Sort-Object LastUseTime -Descending | Select-Object Account -first 1

    $username= $FullUser.Account

    $username

    This script will pull up all the accounts on the pc, sort by the latest used, then output just the latest one's account name.

    Create a procedure that will write this .ps1 file to a pc then executePowershell. make sure you set the "output to variable" setting to true.

    Finally, make sure that procedure then writes this variable to the custom field you created via an updateSystemInfo statement.

    Run the procedure on all pcs, and you'll end up with a column in the Manage Agents view that you can sort. It'll have the accounts listed as domain\user. Local accounts will show as PCNAME\user. It should be very easy to establish which PCs are being used with a local account...

    Let me know if you need any clarification on any of these steps...  

  • Hi Kyle,

    I think we can make this work for what we are trying to do. Although the only portion of this that I am going to have trouble with is the procedure portion, would you happen to have a procedure that will perform what you mentioned?

  • It's pretty easy to collect the information - hostname, active user account, AD or Local. The question becomes - how do you identify the person actually using the computer and those credentials? You can put up a prompt and request the user's name, but will the user respond? Respond Accurately?

    We run regular reports on local accounts and even generate alerts if the local accounts don't match a list of permitted local accounts. Unauthorized accounts are more than a PITA but a serious breach of security.

    If I were tasked with this, I'd:

    Make sure every employee had a valid AD account;

    All endpoints were AD-joined;

    All systems had auto-logon disabled;

    All non-authorized local accounts were disabled;

    All non-authorized AD accounts were disabled;

    Force a log-off of all accounts and require login with a valid, authorized account.

    Glenn