Re: Best Practice for Domain & Local Admins

Hey Susan.

Thanks for the response. Why am I not surprised that the Queen of Security would be the first to respond? :-)

I have a couple of follow up questions:

1) Does "adjusted off lanman hashes" mean that the hash file that gets created for cached logins is NOT created? Can you elaborate a bit?

2) For the 6am report, are you referring to the Security one within Event Viewer that can be included in mailed reports?

3)I'm guessing the answer is yes, but should the pass phrase philosophy be set for BOTH domain AND local admin accounts?

4) I am with you 100% with the whole local admin accounts for the users. In your SBS deployments, do you NOT make the user local admins, and how do you circumvent SBS as far as performing the client-app installs and such?

5) Finally, have you seen Microsoft's Shared Access tool? (www.microsoft.com/sharedaccess) It is pretty darn awesome and can be used in a domain as well.

Thanks again for all the help you give the SMB community!

Alex from Miami

P.S. Just got my MSBS recently....WOO HOO!!!


Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:
I do have a separate local admin account on my workstations than the domain admin account.

I also adjusted off lanman hashes.

But remember .. your 6 a.m. email will warn you about bad password attempts.

Make that admin account a passphrase.

I personally have found there is more risk from workstations running with local admin rights and folks being able to download malware.

I've seen folks bang on the Admin account on port 25.

Look to your real risks.

Alex from Miami wrote:

I was just wondering what others thought of this.

Considering that there are password-breaking utilities out there, would it be a best practice to have two separate admin accounts for our SBS deployments? One would be the system admin account which would be used solely on the physically secured server, and the other would be a local admin account that is just a regular domain user, but is set as an administrator on all local machines.

Here is my rationale:
Since many of the password-hacking systems out there require that the id be stored in a hash file locally, if the domain admin account is not used on the client machine, it's not able to be hashed. Any administrative tasks that need to be accomplished on local machines would use the local admin account. The only place that the domain ID would be used would be on the servers.

Furthermore, could a Group Policy could be created that prevents the domain admin from logging onto client workstations? Would we even WANT to create a policy like this?


-Alex from Miami
.

Relevant Pages

  • Re: Groups
    ... It is a bad idea to add normal users to the admin account, ... legitimate reasons to add certain users to the local admin accounts. ... Power Users can install most - but not all - software. ... Free Computer Help - http://forums.techarena.in ...
    (microsoft.public.windows.server.active_directory)
  • Re: Permissions
    ... The local admin account and password are in sync. ... Joe Richards Microsoft MVP Windows Server Directory Services ... full control share permissions but limited NTFS permissions propagated ...
    (microsoft.public.windows.server.security)
  • Re: SBS 2003 Premium, user changes password and loses network share access
    ... If no local admin account, log on as a domain admin. ... profile that has local admin permissions on the workstation. ... Merv Porter [SBS-MVP] ...
    (microsoft.public.windows.server.sbs)
  • Re: Install program at startup
    ... Will the HKLM\RunOnce run as a local admin? ... When I logged in with an admin account, ... prefixed with an exclamation point to defer deletion of the value until ... command line is run unless overridden as noted above. ...
    (microsoft.public.windowsxp.general)
  • ISA Permissions
    ... The ISA is AD Mode. ... I Installed isa with local admin account, ... domain admin account, I put domain admin account in the ...
    (microsoft.public.isa)
Loading