Enabled Accounts in SolarWinds that are no longer in Active Directory

Hi All,

I'm working on reducing the Account footprint of Users that have access to SolarWinds, and we use a number of Windows Security Groups to manage groups of user access to the console.

I have run a SWQL query via SDK against the 'Accounts' table, and have a list of Accounts that have access to SolarWinds. I have 400 accounts exported into a spreadsheet, all of which are Enabled, some haven't logged on for years, and they will be removed, but, when cross-referencing these accounts with Active Directory I have approximately 110 accounts listed from the SWQL output, that are no longer in Active Directory.

I also have approximately 40 other accounts that are 'Disabled' in AD, but present as Enabled accounts in SW.

I'm more concerned about the 110 accounts that aren't even in AD, but present in the SWQL output as enabled users to SW.

Any ideas?

Find more posts tagged with

active directory

windows groups

permissions

accounts

Accepted answers

tobyw_loop1

Hi Bootneck

If you're using AD auth, and that's the only method to control your access, you have nothing to worry about. If the AD account is disabled, they're not getting access to the system.

If you have individual AD accounts added, you can check for that separately.

I have recently amended the following SWQL and you can adjust based on your requirements. It highlights accounts not logged in with for 90 days.

SELECT AccountID 
    ,AllowAdmin AS [Admin Account] 
    ,DAYDIFF(LastLogin, GETUTCDATE()) AS [Days Since] 
    ,LastLogin AS [Date of Last login] 
,AccountType
FROM Orion.Accounts 
WHERE AccountID NOT IN ( 
    SELECT AccountID 
    FROM Orion.AuditingEvents  
    WHERE ToLocal(TimeLoggedUtc) > ADDDAY(-90, ToLocal(GETUTCDATE() ) ) 
    ) 
AND AccountType NOT IN (4,3,6,0)
AND Enabled = 'Y' 

ORDER BY LastLogin ASC

--Type 4 = AD Account
--Type 3 = AD Group
--Type 6 = SAML Group
--Type 0 = System
--Type 1 = Local Account

tobyw_loop1

Like @mesverrum has mentioned, the entries in the SolarWinds DB are artefacts left over, and as long as they are disabled in your AD environment, there's no way they're getting access to SolarWinds. That being said, there's nothing to say you couldn't strip out the accounts from the Orion.Accounts table that haven't logged in for 90 days, but I would consult with a DBA and ensure you have a full DB backup beforehand.

If you wanted to mark them as DIsabled (safer option) that is also possible, but there is no direct sync between AD / SolarWinds, so this would be a manual process. There are a couple of options here for SQL and PowerShell : Auto Disable Inactive Orion Login Accounts

mesverrum

Im not even sure if removing their group completely would trigger removing their individual entry, for example ive had occasional problems in the past where a user moved between groups in AD that both had access but with different permissions and their Orion account got stuck with the old permissions until I manually deleted their individual entry and it was rebuilt correctly on their next login. So I'm not sure that it does a great job of keeping synced to AD changes except to outsource the actual login approvals.

For reporting and access control accuracy purposes I'm more inclined to use powershell and map the names of the defined user groups back to AD and then take the contents of AD as the source of truth.

All comments

tobyw_loop1

Hi Bootneck

If you're using AD auth, and that's the only method to control your access, you have nothing to worry about. If the AD account is disabled, they're not getting access to the system.

If you have individual AD accounts added, you can check for that separately.

I have recently amended the following SWQL and you can adjust based on your requirements. It highlights accounts not logged in with for 90 days.

SELECT AccountID 
    ,AllowAdmin AS [Admin Account] 
    ,DAYDIFF(LastLogin, GETUTCDATE()) AS [Days Since] 
    ,LastLogin AS [Date of Last login] 
,AccountType
FROM Orion.Accounts 
WHERE AccountID NOT IN ( 
    SELECT AccountID 
    FROM Orion.AuditingEvents  
    WHERE ToLocal(TimeLoggedUtc) > ADDDAY(-90, ToLocal(GETUTCDATE() ) ) 
    ) 
AND AccountType NOT IN (4,3,6,0)
AND Enabled = 'Y' 

ORDER BY LastLogin ASC

--Type 4 = AD Account
--Type 3 = AD Group
--Type 6 = SAML Group
--Type 0 = System
--Type 1 = Local Account

bootneck1111

Do you know why SWQL against Accounts shows enabled SW access when the Accts are no longer in AD?

Thank you for the adjusted SWQL, I'll run that now, I'm just trying to reduce the SW Access footprint in view of Security. Many of the Accts haven't logged into SW since 2020, and we only have Windows/SAML Groups granted access to SW, no individual Accts. However, I have found nested Groups within groups as well..

mesverrum

When orion first sees a user log in then i will create a local entry in the db for that user to manage their preferences and login history and such. If that user disappears from AD SW will never know because it only updates the users when they are able to log in. No AD entry means failed login attempts if someone tries to log in, so nothing gets updated.

Enabled in orion doesnt mean enabled or even exists in AD, just a leftover artifact that the user did exist at some time. Pretty sure you will never see an AD group based user show as disabled unless you disable it in the DB. You could disable an AD individual account to prevent them from logging in later, but there isn't a GUI for managing individuals within a group since that undermines the purpose of that whole group based workflow.

bootneck1111

So the database values aren't 'True', in that, I believe when running the SWQL query against 'Accounts', that there are 400 Enabled Users that have access to SW, when in fact, this is not the case, even if the individual users are removed from the specified Windows Groups.

So to get round this false data in the SW-DB, could I 'remove' the Windows Groups' in 'Settings/Accounts', and then re-add them with the Updated AD Windows Group? Would that then update the SW-DB with true values, or are those Account Metrics now stuck there, and only likely to increase in number?

As a Security Team it's our job to reduce the SolarWinds footprint in terms of Unnecessary User Access, certainly for those members of staff that have left the business but still have a visual presence as a user account going back as far as 5 years, in the SW-DB

bootneck1111

Can I remove these account in SolarWinds via editing 'Database Manager', or at least mark the account value as 'Disabled'?

bootneck1111

Thanks Guys, very much appreciated. Some of the accounts last logged on back in 2017 so those ones certainly will be stripped out, but as you've all pointed out, AD will govern access to SW via those active Security Groups. Most of these historic Users are individual users, whereas all I can see in Accounts is Groups, so not sure if they were from before I started, or these individual users have been picked up from the Groups which I would expect.

HerrDoktor

There should be a field somewhere with the Group-SID or something. If that field is empty, it’s an individual user, if the field has a value, it’s derived from a Group Login. I can have a look in SWQL Studio later and update my post here.

kenyamson

I encountered the same problem recently, and we ended up disabling the user in Active Directory.

I explored all possible methods to disable the user in SolarWinds, including using the API, SDK, and manually editing the database, but the 'enabled' status always reverted, even when I set it to 'N' or 'False.'