Best practice for Inactive accounts

Posted on 2014-09-11
Medium Priority
Last Modified: 2014-09-23
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, ......
Question by:sunhux
  • 4
  • 3
  • 2

Author Comment

ID: 40318452
I felt it's not feasible to reactivated "Inactive' accounts as it's impractical
LVL 66

Assisted Solution

btan earned 1200 total points
ID: 40318726
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.

Author Comment

ID: 40319022
So it's better to leave an Inactive account in 'disabled' state or
reactivate it every 90 days by sysadmin ?
WEBINAR: GDPR Implemented - Tips & Lessons Learned

Join the WatchGuard team on Thursday, March 29th as we recount some valuable lessons learned in weighing the needs of a business against the new regulatory environment, look ahead at the two months left before implementation, and help you understand the steps you can take today!

LVL 66

Expert Comment

ID: 40319041
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!
LVL 38

Assisted Solution

by:Rich Rumble
Rich Rumble earned 800 total points
ID: 40319253
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)
LVL 66

Assisted Solution

btan earned 1200 total points
ID: 40319454
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

Author Comment

ID: 40323441
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
LVL 38

Assisted Solution

by:Rich Rumble
Rich Rumble earned 800 total points
ID: 40323690
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.
LVL 66

Accepted Solution

btan earned 1200 total points
ID: 40324425
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...http://demo.protocolpolicy.com/PCIDSS.html
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.

Featured Post

Managing Security & Risk at the Speed of Business

Gartner Research VP, Neil McDonald & AlgoSec CTO, Prof. Avishai Wool, discuss the business-driven approach to automated security policy management, its benefits and how to align security policy management with business processes to address today's security challenges.

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.

Join & Write a Comment

The article explains the process to deploy a Self-Service password reset portal I developed a few years ago. Hopefully, it will prove useful to someone.  Any comments, bug reports etc. are welcome...
A discussion about Penetration Testing and the Tools used to help achieve this important task.
Sending a Secure fax is easy with eFax Corporate (http://www.enterprise.efax.com). First, Just open a new email message.  In the To field, type your recipient's fax number @efaxsend.com. You can even send a secure international fax — just include t…
Is your data getting by on basic protection measures? In today’s climate of debilitating malware and ransomware—like WannaCry—that may not be enough. You need to establish more than basics, like a recovery plan that protects both data and endpoints.…

619 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question