Can someone give me the advantages and disadvantages of deleting user account from AD when the user leaves the company? It has always been drilled into me to never delete the account.Thanks-

Hello,ther is no need for keeping them and you can safely delete them. How long you wait for deleting depends on your company policies. If our users leave i get an info and then delete user accounts, profiles stored on the serverand mailboxes.But there is no reason that they should never be deleted. Technically nothing is against this.Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights.

HelloAdv: None..Maybe use might be rehired? but them you can just recreate account or re enable account if it was disableDisAdv: user is gone for good, why keep the account..someone else might impersonate user , or user might try to use account from somewhere and cause havoc on your networkThe least you can do is DISABLE the account if you don't want to delete itIsaac Oben MCITP:EA, MCSE

While there is no *technical* reason you shouldn't delete a user or group account, for many (most) organizations there are very real practical side effects of doing so. The reason you want to disable, rather than delete, group and user accounts is very simple: Auditing. Bob gets hired, logs onto his workstation and proceeds to go about his daily business. He writes emails, copies files to and from file servers, edits intranet pages, etc. Bob leaves to go to another company and his user account is deleted. Alice gets hired, logs onto her workstation and proceeds to go about her daily business. She writes emails, copies files to and from file servers, edits intranet pages, etc. Alice leaves to go to another company and her user account is deleted. ... Five years later, after about 100 users or so have all came and went, somebody stumbles upon a folder on a file server containing sinister documents. Who did they belong to? When you look at the file information, the owner cannot be determined. All that is left is an old, unloved unique identifier (an SID under windows, or a UID under *nix.) Under windows, if you absolutely need to figure it out, you have the option of painstakingly combing over HR and audit logs to try and figure it out (SSIDs are sequential). Under *nix, the situation is even more dangerous, since it handles authentication/authorization quite differently. Windows passes around authorization data in a kerberos authentication ticket, which is then used to grant or deny access to a resource. Windows will never reuse an SID. Under Unix, however, Authentication and Authorization are two distinct processes. First a user proves who they are (authentication... local /etc/passwd, ldap, kerberos, whatever), then the session is built by looking up the corresponding username's authorization in the passwd and groups databases and spawning a shell. Most (all?) "adduser"-esque tools don't track will use the next available UID, that can easily conflict with a deleted user, not only granting alice access to all of Bob's remnant documents, but also making it impossible to determine if a file was created by Bob or Alice. (timestamps can be manipulated.) This is the trivial example, and trust me even more quirky stuff will pop up on large, long lived networks. Listen to the grey-hairs you encounter in your career. They may seem stubborn and nonsensical sometimes, but more often than not, there's a method behind their apparent madness. -s