Re: DC Admin question

"Jesper" <Jesper@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D8715ABA-8D83-43FC-B1AC-DF2E32A50C9D@xxxxxxxxxxxxxxxx
Actually, as I think Joe was hinting at, with physical access to the box
you've pretty much already decided to trust the IT guy as a domain admin.
If
he's evil, he's got all the access he needs right now. If he's not, you
may
as well give him a domain admin account.


That is theoretically correct.
Personally, I think there is a middle ground between the "if they
are evil and if they are not". If they are well intended, and
would not elevate themselves, then they may be careful or
wreckless as far as exercise of administrative empowerment.
Due to that, for me the "you may as well give" admin is if
fact a non sequitur; some people simply should not log in as
an admin (perhaps after they have screwed up play/test boxes
for sufficiently long <g>).
If they are malicious and will/can act on that intent, yes, just
having them in the same room is a problem. But I assume that
they have made something of a good hire (foolish me).


You have to be an admin to install printers because they use kernel mode
drivers.

Actually, we are jumping the gun here.
First off, we do not know the scenario. Is the printer local to the DC,
or a network device, to which the users print directly or via a printer
defined on the DC. The use case has bearing on the driver install need.

It sounds as though the poster speaks of defining a printer (i.e. making
a print queue) from square-one (initial setup of that device's drivers),
but I cannot ascertain local or network attachment.

If it is local, then doesn't its installation actually depend on whether it
is
a pnp device or if the printer's driver signed is and present in drivers.cab
as to whether SeLoadDriver privilege (which is what it would seem the
policy "Allow users to install printer drivers" setting grants) is needed
or sufficient/insufficient ?

Anyway, I find the MS approach with this policy confusing as to just
what they wanted it to do compared to what it does do; but, as I did
initially post, one does not want to grant this privilege on a server.


You can't manage shares without being an admin either,

I guess that depends on what one understands by "manage"
Most of what I experience is dealing with what is in the shared
area, plus share creation and initial share-level permissioning.
It is only the last part that requires an elevated account. As to
user share use, many are actually happy to have everying ordered
in a single mapping, rather than spread in multiple shares. Hence
I believe there is in fact a real alternative here that does not mean
the tech needs authority, provided only a properly set up area is
provisioned for their use.

so the decision is quite easy.

The read-only DC in Longhorn will be great for this type of scenario.

Not really. The read-only DC will just protect AD.

Were the poster to flesh out the "etc" we would find more that falls
into the case as for printers, where granting Administrators group
membership would appear to be the most direct resolution.
As such, I feel that alternative deployment choices are the route
(such as I provided with the shares case, or as one attains by making
one of the office machines the print server).

Roger

"Roger Abell [MVP]" wrote:

You would need to give him login rights to that DC only, using a GPO
to grant the Logon locally user right, which same GPO applies not to
all DCs in DCs OU, but to just that DCs. In doing this one must keep
in mind that the list of grantees will replace, not augment, the list as
stated in the GPO hierarchy impacting the DCs in general, so it must
be a mindful, and complete list.

Now, that would let you grant a non-admin local login rights to the
specific DC. However, what can that non-admin then do?
You indicated "manage user shares, setup printers, etc", so much is
in the "etc".

For shares, you could preconfigure some top-level shares, with
share-level permissions for admin access and a Change grant to
the sum of all domain user accounts that would be active at that
location, and then grant the local IT contact group control on the
content (at NTFS level) below the pre-configured, shared dirs.
Of course, if you also granted the local IT contact group a Full
share-level grant, then they could manage the storage using a
mapped drive and would not need local login to the DC.

Printers are more difficult, as this involves an install, and in
particular a driver install. Granting this capability to someone
on a DC gives them the foot-in-the-door by which with skill or
luck in downloading, they could effect elevation of their account
(potentially making them able to act as if any account of any of
the domains in the forest). There is however a policy to prevent
install of printer drivers by users, which is normally enabled (i.e.
normally prevents). I would not recommend changing this.

Now, what else is in that "etc"?
It comes down to a question of just how much you are willing
to place at risk, given that some actions, once done to AD will
have broad effect everywhere; and given that with sufficient
skill (or research) and will someone with access to those enabled
credentials can elevate their privilege level.

Roger
"jim" <jim@xxxxxxxxxx> wrote in message
news:e5CTVK9OHHA.400@xxxxxxxxxxxxxxxxxxxxxxx
We've got a DC at a remote site that doubles as the office's file/print
server. The problem is that we need to allow our local IT contact to
manage user shares, setup printers, etc, but we're not sure how to give
him logon rights without making him a domain admin.

Does anyone know of technet white paper (or something) that explains
how
to get around this?

Thanks in advance!






.

Relevant Pages

  • Re: DC Admin question
    ... you've pretty much already decided to trust the IT guy as a domain admin. ... You have to be an admin to install printers because they use kernel mode ... that would let you grant a non-admin local login rights to the ... You indicated "manage user shares, setup printers, etc", so much is ...
    (microsoft.public.windows.server.security)
  • Re: domain admin user who cant add other people to the admin group?
    ... You most definitely don't want to make them a domain admin, ... container (or the OU where you place computers). ... To allow creation of shares, make the user (or preferably a group created ... which contains the user) an administrator only of the file ...
    (microsoft.public.win2000.active_directory)
  • Help... need to give out access..
    ... printers and shares, and be able to shut down the DC in ... case of emergency... ... access without making them a Domain Admin? ... Prev by Date: ...
    (microsoft.public.windows.server.active_directory)
  • Re: FW: Remotely Sharing ?
    ... > domain admin)? ... > Any text/gui facilities would be great. ... (to remotely access the program, ... In there, you can create new shares, change ...
    (Focus-Microsoft)
  • Re: Win2000 Directory Security
    ... If you are a domain admin, and the machine is part of the domain, then NO. ... you can grant yourself the necessary access to give ... > I am administering a win 2000 IIS server remotely. ...
    (microsoft.public.windows.server.security)