Best security practice with Systems created accounts

In the system scan by security officer, they've found a few AD
& local accounts : my colleagues renamed the Window guest
accounts to these accounts & disabled them.  

In UNIX/Linux, we have lp, adm accounts etc which my
colleagues disabled them.

Q1:
Security officer recommends that these accounts be deleted
instead of just being disabled.  What's the best practice?
Delete or just leave them disabled?

Q2:
What are the impacts/implications of removing system
 created accounts?   Can go thru the impact of removing for
 each account (I only know about 'guest' in Windows but I
 see ASPNET account as well;  for UNIX,  there's uucp,
 adm, bin, daemon, ftp, nuucp, lp, tftp)

Q3:
Do people generally rename the Windows local administrator
as a good security practice?  What about renaming UNIX root?
sunhuxAsked:
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.

Netman66Commented:
Well, I think you'll find the Guest account - even though it's disabled is needed for generic share permissions behind the scenes.  Not sure you can remove it and if you do, it may impact non-published accounts like the "Everyone" group.

As for renaming the Administrator account, you should do this as best practise and it should be done (correctly) via Group Policy - rename Administrator account so that underlying registry settings get updated too.

As for linux, I'm really not sure you can rename the root account - but, of course, I could be wrong since *nix is not my strength.

The ASPNET account as well as others has extremely limited access (as does Network, Local, etc) and this is by design.  You can check the local Group Policy and see that these accounts don't even have "Allowed to Logon" rights.  They are simply there to run services in the background and nothing else.
sunhuxAuthor Commented:
As we're not certain if there's any impact of removing & we don't have
a test/staging environment to test out if removal of guest could have
any impact, is there any  way that we can take a backup (of which files
/folders), then remove them.  After a couple of months, if nobody shouts,
then we can safely say, there's no impact.

Just renaming & disabling guest alone is not a sufficient test that removal
of guest is harmless.

We have a couple of AD accounts too that have been disabled & security
officer insists they should be deleted in case an unscrupulous sysadmin
or someone accidentally enable it back & thus opens up a vulnerability.

Likewise for Linux/UNIX's sys, adm, lp, ... accounts.

Can EE moderator add this thread into UNIX domains as well so that
 *ix  experts can respond on the impact to sys, adm, ...  accounts?
Rich RumbleSecurity SamuraiCommented:
You can't delete the guest account, nor any of the default accounts (admin and guest) :(
http://technet.microsoft.com/en-us/library/cc755130.aspx
Renaming is fine, however it's security through obscurity, the SID of the accounts does not change, and the SID is often part of the authentication process.
https://support.microsoft.com/kb/243330
http://msdn.microsoft.com/en-us/library/cc230371.aspx
Nonetheless it is a recommended practice, even it's pretty easy to use any account in AD and figure out the administrator account. There are also SID enumeration utilities and methods.
System created accounts can be placed in more restrictive groups to help mitigate their potential abuse.
http://technet.microsoft.com/en-us/library/cc756898%28v=ws.10%29.aspx

For unix it's about the same, you can certainly rename "root" to something else, it's not as easy as windows to figure out who is root. You should disable or remove when possible any accounts not needed. A few weeks or months should be an effective amount of time to tell if the account will be missed or not.
-rich
CompTIA Security+

Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.

sunhuxAuthor Commented:
Hi Richrumble,

http://technet.microsoft.com/en-us/library/cc755130.aspx
I can't find any mention in the above link that Guest can't be deleted;
closest is it recommends to disable it.  The portion most related to
this is extracted below:

You can set rights and permissions for the Guest account just like any user account. By default, the Guest account is a member of the built-in Guests group and the Domain Guests global group, which allows a user to log on to a domain. The Guest account is disabled by default, and we recommend that it stay disabled.
sunhuxAuthor Commented:
Which files & folder(s) can we backup so that we can restore back
a deleted account (AD & local)?
Rich RumbleSecurity SamuraiCommented:
You cannot delete any built-in accounts, see the screen cap attachment.
-rich
guest-delete.JPG

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.