|
Posted by Roger Abell [MVP] on January 20, 2007, 7:10 am
Please log in for more thread options > 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
>> > 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!
>> >
>>
>>
>>
| 
XML Sitemap