I don't mean disabled... and I'm hoping for something other than "exported". Here's my problem: My org never deletes accounts (just disables them)--not my call. I've hidden the disabled accounts from browsing with a custom filter "(!(userAccountControl:1.2.840.113556.1.4.803:=2))", but this doesn't hide from things like group membership lists (and with the "turnover" rate here, my AD is getting extremely cluttered). Does anyone have ideas or proven solutions for "archiving" user accounts in such a way as they are removed/hidden from AD (or even just my domain, group membership lists, etc), but easily put back just as they were? The primary purpose of not deleting accounts is preserving all attributes (including things like group membership) if the account is reenabled... so any sort of removal/archival needs to be able to preserve these. Attributes need not be easily accessed while the account is disabled or "archived".
SnapOverflow
You really need to go back to the drawing board with your account lifecycle management.
If you're keeping old accounts hanging around in the event someone comes back, it's actually pretty poor practice from a infosec point of view. Someone may not return with the same role they previously had and they should potentially not have access to everything they previously had.
It's also best practice for someone's account access to be specifically requested/reviewed when they're onboarded. Maybe it's a slight PITA, but at the very least, the hiring manager could say that $returnedStaffMember needs the same access as $otherPerson (still not great practice, but adequate).
Permissions creep is a well-known problem in any security environment and this kind of thing is a classic example of how that happens. I know of someone who was a senior public servant (reporting to Cabinet) who had a former staff member gain access to their mailbox when the staff member was re-engaged after a several-years absence - in a different department with a lower security clearance. Fortunately the individual reported the issue due to their account being re-enabled - it wasn't just one mailbox that they shouldn't have access to (and that dept has stopped the practice).
Normally, you would give a grace period to retain the account past their termination date. The expectation would be that they return to the same role to have the account re-enabled as-is. Perhaps one or two pay periods or even something like 6 months. There should be a way to identify accounts where the staff member is on long service leave/sabbatical or parental leave. Then you have the AD Recycle Bin (but more than 6 months retention is a lot anyway).
As mentioned, there are backup products where you can do a "brick-level" recovery of someone's account, but again, how long do you offer that for? Same issue with permissions creep over time and lack of account governance/review.
You could do a "cheap person's" archive with dumping the account's main properties and group memberships, including the SID for audit purposes (in the event security logs need to be reviewed), and stick that somewhere like a database. You'd also want a way to positively identify that it's the same individual, such as birthdate or HR record ID (if you have an HR system that generates unique permanent IDs for staff) - people often have duplicate names.
Ideally, a more sophisticated system taking input from HR and assigning the user to the appropriate groups etc depending on department/role would be the way to go - products like MIM, NetIQ etc etc.
But in the meantime, allowing your accounts to linger forever leads to a huge amount of bloat in AD, and it is explicitly classified as poor practice by Microsoft and many infosec authorities. Allowing obsolete accounts to remain in groups in particular will eventually lead to performance issues for the other accounts in the same groups (beyond just the general security concerns, "messiness" and AD performance as a whole).
No way. Attributes are filled up with working values. Either you delete an account (and even in this case the account SID will persist in ACLs) losing all the information once the object gets tombstoned - if the AD recycle bin is enabled - or you just disable it (and the account SID will be resolved to its correct name when browsing ACLs).
In enterprise directories an Identity management solution (f.i. MIM ) is usually implemented so part of the issue is managed by software.
Note that you can take a backup of the active directory database and later on mount the backup and browse a previous version of a directory, and eventually restore an object.