Local accounts for domain users best practice

Discussion in 'Windows Small Business Server' started by CourtK, Feb 25, 2010.

  1. CourtK

    CourtK Guest

    We have some clients that have the domain user in a local administrator
    group only, no local account. What are best practices for adding domain
    users to the workstations? In an environment where the users do not need
    roaming profiles, is it advantageous to set up local accounts for the domain
    user? Could not having a local account cause the profile to be volatile?

    Thank you,
    CourtK, Feb 25, 2010
    1. Advertisements

  2. CourtK

    Joe Guest

    The best practice for a Windows domain is to have no local workstation
    users or membership of local groups at all. Local accounts have no
    connection with any domain which may exist on the same network.
    Presumably the customer is using the Microsoft domain model of
    networking for a reason?

    The addition of users to the local administrators group makes the
    computer completely vulnerable to any malware that they might run, and
    it is therefore considered a poor idea. Unfortunately some companies
    produce software which can only be run by administrators, indicating
    extreme ignorance on the part of their programmers concerning the
    platform they use, and requiring hope and faith that their grasp of the
    business application is somewhat better.
    Joe, Feb 25, 2010
    1. Advertisements

  3. CourtK

    CourtK Guest

    Let me rephrase this,
    If we want the user to be a local Power User or local Administrator is it
    best to add the domain user to a local group, with no specific local
    account, or to add a local account?
    CourtK, Feb 25, 2010
  4. Don't use local accounts. There is absolutely no benefit and it only makes
    management more difficult.

    Cliff Galiher - MVP, Feb 25, 2010
  5. CourtK

    CourtK Guest

    That is not an option. To clarify even more, this question is regarding
    adding domain users to a local account on a workstation, not the SBS server.
    CourtK, Feb 25, 2010
  6. CourtK

    kj [SBS MVP] Guest

    Add domain accounts to workstation local groups. This is done by default for
    you for domain users -> Users, and Domain Admins -> Administrators.

    If you want a specific domain user in the local power users or local
    administrators group - do it.

    Don't create local user accounts.
    kj [SBS MVP], Feb 25, 2010
  7. CourtK

    SteveM Guest

    I think you need to explian *why* you want to do this. The responses
    you've had are the expected ones - don't make domain users local
    admins, and don't set up local admin accounts for them (which will
    result in allowing users to circumvent domain restrictions on the
    workstation). The whole point of a domain-based network is to enforce
    central management and control. If you're going to allow local control,
    it undermines the whole secuity model and puts your network at risk.

    So, if you can explain what it is you want to achieve, and why, people
    might be able to help you more.
    SteveM, Feb 25, 2010
  8. CourtK

    CourtK Guest

    I am fairly certain that Microsoft supports adding a domain user to their
    workstation as a local account, considering Microsoft prompts for it during
    the join to domain wizard and, during the process to add a local account, I
    can select domain users in AD.

    If a local administrator account is used IT doesn't have to be involved when
    users want to add hardware and software. I believe not adding a domain user
    to a local account or local group defaults to a user account, which can't do
    much of anything. Some of our clients want to be able to install software
    and we have to oblige.

    So, getting past whether or not to add a domain user to a workstation's
    local account, which method is best practice; to add a domain user to a
    workstation's local group or setup a workstation's local account? Could
    adding a domain user to a local group, and not creating a specific local
    account, cause local profile issues?
    CourtK, Feb 25, 2010
  9. CourtK

    kj [SBS MVP] Guest

    Going to agree with SteveM here. Your nomenclature usage is just confusing.
    What are you trying to acheive?
    kj [SBS MVP], Feb 25, 2010
  10. CourtK

    CourtK Guest

    Add a domain user to a workstation and allow them to install software and
    hardware without IT intervention.
    CourtK, Feb 25, 2010
  11. CourtK

    SteveM Guest

    to oblige.

    Some of our clients also want to engage in activities which are
    dangerous to their networks. It doesn't mean we have to oblige.
    Instead, we talk them through the consequences of what they want.
    Mostly they relent, in the knowledge they are doing the right thing. If
    they don't we have them sign up to a disclaimer which absolves us from
    any responsibility for their chosen actions (in other words, they have
    to pay extra for us to fix the mess they - inevitably - create).
    SteveM, Feb 25, 2010
  12. CourtK

    CourtK Guest

    Rather than using my nomenclature I'll describe the steps involed for the
    two ways to add a domain user within Vista.

    Click Start \ Control Panel \ User Accounts \ User Accounts \ Manage User
    Accounts \ Add \ type user name \ type domain \ select Administrator (or
    whatever) \ Finish


    Click Start \ Control Panel \ User Accounts \ User Accounts \ Manage User
    Accounts \ Advanced tab \ Advanced button \ expand Groups \ double click
    Administrators \ click Add \ type domain user \ click OK

    Which one is best practice?

    CourtK, Feb 25, 2010
  13. CourtK

    kj [SBS MVP] Guest

    This is acheived by adding the domain\user accounts to the workstation local
    group that has permissions to perform the desired operations.

    Worksation accounts are authenticated by the worksation and have no rights
    on the domain.

    Domain accounts are authenticated on the domain and given (delegated) rights
    through workstation local group membership.

    However the side issue remains that workstation users really shouldn't be
    arbitrarly installing stuff. Unless the user happens to "own and self
    support" the workstation. It's just a bad practice that should be avoided
    whenever and however possible.
    kj [SBS MVP], Feb 25, 2010
  14. CourtK

    Joe Guest

    We seem to be fumbling towards understanding here, but this is one point
    that should be clarified: when the connectcomputer wizard asks you to
    designate users, it is *not* creating local accounts.

    It is changing some group memberships, not in an optimal way, and it is
    migrating any previous local profile of that name so as to be utilised
    in a domain logon. That is not the same as creating a local account.
    Local accounts in a domain are as welcome as... no, I'll stop there.
    *Not* welcome.

    I'm sure you don't want to be lectured on security, but your subject
    line does include the phrase 'best practice'. Whether your clients wish
    to hear it or not, 'best practice' includes *never* giving users
    administrative logons. With Vista, that is finally possible, as there is
    almost no job that actually requires an admin to be logged on. So those
    users who can be trusted can be given partial administrative accounts to
    use *from* their unprivileged accounts. And that's *domain* accounts,
    which can be controlled by policy, and which the user cannot reconfigure

    That's not some theoretical ideal, a 'do as I say but not as I do'
    proposition. I'm sitting now at one of my computers, my own personal
    property, to which I've never logged in as administrator since the day
    it was installed, and I never expect to do so. I do a lot more admin
    work on it than most 'power users' ever do, but I take admin privileges
    only for the duration of a particular job, in one window of my desktop.
    I have no boss, so it's not control freakery, it's common sense.

    Quite apart from security, another 'best practice' is to maintain the
    workstations of a network in as uniform and unconfigured a state as
    possible, to make life much easier when one breaks. Ideally they should
    all be identical, but for some reason, probably quantum, that doesn't
    seem to be possible.

    Even if each user only ever logs on to one machine, it's still a good
    idea. Do all the individual configuration using domain facilities,
    that's what they're for. Altering the logon permissions of a couple of
    users is a whole lot easier than looking up the documentation (!) for a
    couple of machines and installing software and adjusting one to match
    what the other used to be.
    Joe, Feb 26, 2010
  15. CourtK

    Steve Foster Guest

    Best Practices:

    1) *never* create local accounts, ever.
    2) disable (via GPO) the pre-installed local Administrator and Guest
    accounts (<Local>\Guest is disabled by default).
    3) don't grant users administrative privileges anywhere.

    SBS2003 deviates from the above, in that it routinely assigns users local
    administrative privileges (for the PC assigned to the user at user
    creation). SBS2008 doesn't make this mistake any more.

    By default, all domain user accounts can log on to any domain-joined
    workstation. Nothing needs to be done to any workstation to achieve this
    (beyond the original joining to the domain).

    The decision on whether to roam or not to roam domain user profiles is
    entirely unconnected with the above.
    Steve Foster, Feb 26, 2010
  16. CourtK

    CourtK Guest

    I apologize for making this such an annoying issue and I agree that there
    must be a "fumbling" of terms and understanding here but I would really like
    to get my intentions resolved.

    Joe, you inspired an idea to get my answer, which was to use the SBS connect
    wizard and see how the domain users are added. After using the SBS
    "connect" wizard, the domain user was added to the "User Accounts" menu, not
    just a local group.

    So, if I were to do this manually (not using the SBS connect wizard) I would
    do it this way:
    Click Start \ Control Panel \ User Accounts \ User Accounts \ Manage User
    Accounts \ Add \ type domain user name \ type domain \ select group \

    Going with what you say how
    CourtK, Mar 2, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.