Best practice for Inactive accounts

We have 2000 odd accounts (of OS, applications, network devices that are created locally
as we don't use central authentication like TACACS/Radius currently) that become "Inactive"
(& 'locked') after 90-days as users don't always login.

Our governance chap insist that we must raise SR every month to 'reactivate' (or re-enable
back) those Inactive accounts that are still needed rather than leave them as 'Inactive'.

My view is it's best to leave them as 'Inactive' because reactivating an account that is not
being used will subject it to being misused or subject to 'brute force' attempts to break in
but governance chap pointed out that it's a corporate policy & escalated, demanding that
it's either deleted or reactivated.

So what is the best security policy?  I determine if an account is still needed by emailing
the individual users (& their management) & for those still needed, leave them as 'Inactive'
till the user raise an SR to reactivate as & when they need to use the account again

Any authoritative document/link/sites to support the best practice will be much appreciated?
Eg: CIS, CISA, ......
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

sunhuxAuthor Commented:
I felt it's not feasible to reactivated "Inactive' accounts as it's impractical
btanExec ConsultantCommented:
inactive accounts (some called it dormant)  are accounts not used for a period and in your case, for permanent basis or long period. there should be immediate deactivation and removal but most of the time, the suspension (or locking) come is after such as 40 days then deactivated (or even remove) permanently if not used or required after 90 days.

If it is to relive the suspended account then an active user need to be using that or for the purpose of required and authorised functionality. Noted ideally, it is not any other user but the one assigned to it  originally as good practice in view of account usage and abuse. If the latter is not approved by mgmt, there is no good justification to relive it - in fact it is false impression that it is going to be used for legit purposes and worst still, this conflict the state of evidence such as evidence falsification for sake of compliance - it is all total non-compliance.

Policy wise, it is necessary to determine the necessary duration of inactivity before an account can be locked/disabled. This policy can vary depending on whether the account is of a normal user or an administrator. For example, for more stringent organisation, disable normal accounts after 45 days of inactivity and administrative accounts after 30 days of inactivity.

e.g. PCI DSS requirements state that a user account should be locked out after no more than 90 days of inactivity. (8.5.5 Remove/disable inactive user accounts at least every 90 days)
e.g. NIST ( User IDs that are inactive for 90 days must be disabled)

There is also an instance of the Org policy -  e.g. systems will disable user accounts automatically after forty days of inactivity. A Security Contact may re-enable accounts disabled in this manner if they are still required.

However, do note that the Org has the Systems to decommission Users’ user IDs automatically ninety days after a user ID has been disabled.  These user IDs will no longer be available for reactivation in the identity management tool by a Security Contact.  However, these user IDs will be available for investigation if required.

Furthermore, it is not even good industry practice as stated in SAN critical controls - see means to validate any claims and due diligence for compliance e.g. Attempt to re-use a user account password that was previously used for the account. Verify that the system requires unique new passwords during each update.

In all good practice and enforcement, the evaluation team must verify that the list of locked-out accounts, disabled accounts, accounts with passwords that exceed the maximum password age, and accounts with passwords that never expire has successfully been completed on a daily basis for the previous 30 days by reviewing archived alerts and reports to ensure that the lists were completed.
sunhuxAuthor Commented:
So it's better to leave an Inactive account in 'disabled' state or
reactivate it every 90 days by sysadmin ?
Top Threats of Q1 & How to Defend Against Them

WEBINAR: Join WatchGuard CTO and our Threat Research Team on Aug. 2nd to hear the findings from our Q1 Internet Security Report! Learn more about the top threats detected in the first quarter and how you can defend your business against them!

btanExec ConsultantCommented:
once user left organisation or account not in use for (example) 90 days, account should be inactive or suspended. there is no use for this account but we may not want to remove it as to retain the inactive account for investigation if policy required. ideally immediate removal is best!
Rich RumbleSecurity SamuraiCommented:
IN Active Directory... Inactive stays inactive and or disabled. Deleting will cause issues as group memberships are based on the SID of the accounts. SID's are never repeated, and you cause more harm than good if you do need that account again.
Policy should be changed, not the best practice. Accounts that are disabled are arguably as secure as having no account.
This is why the Local admin is Disabled BY DEFAULT in win 7 and after: (it's also hard to delete that particular account)
btanExec ConsultantCommented:
indeed not many delete the account esp if it is of admin and service scheduled or batch job under those accounts...but for normal users that is a period for its running and have it eventually planned for. Actually the identity access mgmt will be handling all this deprovisioning of account triggered by HR etc and should be transparent but most of the time it is disparate service and project sprawl that make it difficult. ... as a whole for the user mainly the below may be consider.

Go through their desktop (My Documents and Desktop usually) and archive their old data to the archive fileserver
Back up their /user folder on the regular fileserver to the archive one as well.

Back up all their emails (either in pst or just save their mailbox, depending on OS) and put it in a safe place. Sometimes managers need access to ex-employees mailboxes to retrieve specific emails. If needed we set up an email forward to a manager or coworkers account until there is no more mail coming through.

anyway - "Best Practices" don't always happen in the real world, below is one useful tip 
I like to disable the accounts first before I delete them. If you find that one of these accounts is needed, it is much easier to enable the account than to restore it. Some administrators like to move all of these user accounts to a separate OU, and disable all the accounts for X number of days before they delete them. This will work most of the time. But I do not like doing it because you can run into some issues. For example, you could run into people who have the same name. You cannot have identical distinguished names in AD, so if you try to move one, you will get and error message
sunhuxAuthor Commented:
In my case, we have quite a number of users who had not left the
organization or the project yet & they have emailed me to say they
will still need their accounts (could be an application account like
a CRM or Service Management accounts) but they may sometimes
not use their accounts for more than 90 days.  So their accounts
got 'disabled' by the app or system.

So my contention with the governance officer is:

a) I should just leave the accounts as disabled as long as
    the users (or their managers) confirm they still need it
    ie the way to re-certify is by verifying with the users
    & not take things into my hands to either delete or
    re-enable an Inactive (for >90days) account

b) governance wants me to raise Service Request to re-
    enable or reactivate them each time (or rather on a
    monthly basis) I spot a disabled account that is 'disabled'
    but still needed by the user/owner.  My argument is: we
    should just leave such accounts as disabled till when the
    user needs it, the user raise a Service Request to enable it.
    Governance wants me to be the one to raise SR to re-
    enable or to delete Inactive accounts (ie I can't leave it
    in disabled state)
Thus I was looking for authoritative links / docs to support
my stand for the above 2 points
Rich RumbleSecurity SamuraiCommented:
I concur, your adding a lot of overhead if you are reporting on accounts that are still disabled each week or whatever. You don't need much more evidence than common sense. A disabled account is just as effective as a deleted account, the advantage is that you don't break as much enabling the account vs deleting the account. Again, and it depends on your application, but in AD as an example, deleting an account from AD, will then break the groups that account was a part of. When you go view the groups you will be greeted with an unknown SID. You'd have to delete all the unknown SID's from all the other groups to fully remove that account. Recreating the user account, will not recreate the SID, and it will not rejoin that user to those groups, you have to do it manually.
Other systems it doesn't matter as much, deleting an account and recreating it will work on some of the simpler user stores out there, like MySQL for example. CRM app's often base their access on username only, so it won't matter to that application much. AD and other more advanced authentication systems however, it makes no security sense to use delete as opposed to disable.
btanExec ConsultantCommented:
agree and see the practical aspect - governance folks is just following their "book" in stringent manner. they are not wrong and neither is your rationale as the legit user is still around and not active in the sense the system deem or is configured to be. I do not see that you need example for such operationalisation aspects for the policy aspect - rightfully if it state after 90 days disabled it or deleted it (which as almost working at the same premise of inactive acct), it required deviation sought - that is by the "book"..

I do not really see that they are stopping you folks and if end user can warrant they required the account in their presence, your justification is better raised with some letter of undertaking sign off by end user and in concurrence with the supervisor being consulted and supporting this up for governance team to seek the final conclusion (when getting their internal process approval). they need some black and white to push up for justification and it is part of due diligence. It is better to err on the safe side as default due to inactive or redundant accounts being easily exploited by insider ... risk is lower as it is internal staff but not be taken for granted too..

taking reference from PCI DSS...
8.1.4 - Remove/disable inactive user accounts at least every 90 days.
Observe user accounts to verify that any inactive accounts over 90 days old are either removed or disabled.

Minimally we are saying these account are of lower risk as they are NOT
-Generic user IDs and accounts are disabled or removed
-Shared user IDs do not exist for system administration activities and other critical functions
-Shared and generic user IDs are not used to administer any system components.

And necessary measures are taken as well.
-Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts
-Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access
-Verify use of identification and authentication mechanisms is logged.
-Verify all elevation of privileges is logged.
-Verify all changes, additions or deletions to any account with root or administrative privileges are logged.

Of course, we are talking about the risk assessment and the risk register should be addressing if there are any residual risk and in any ways, there should be clear instruction and record for account mgmt in parameter field as supporting evidence for each account state - security is not about compromise only but striking a balance and no point hitting it hard to proof one side wrong which is lose - lose..

This command accepts the user name via either direct parameter input or via pipeline.  
 .Parameter Requestor
  The name of the person requesting the disable.
 .Parameter ProcessType
  This lets us know if it was done manually or through some other process.
 .Parameter Justification
  This is the reason that the account is being disabled.
 .Parameter Notes
  If we also want to disable the users Notes account, this field needs to be marked with a "Y".
 .Parameter Admin
  Setting this to "Y" will disable the user account and move it to the Pending Delete IT Admin OU.
 .Parameter WorkOrder
  The Service Desk Work Order number related to this disable.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.