List Archives

This forum is an archive of all posts to our mailing list over the past few years. The forum is set read only therefore to contribute you will need to join our list community. See more info about this here.

List Archives

Unanswered Active Topics

Forums Search

Forums >ActiveDir Mail List Archive >List Archives

Subject: [ActiveDir] Rights required to publish printer in AD

Prev Next

You are not authorized to post a reply.

Page 2 of 2

Author

Messages

danholme

Posts:94

listmail

Posts:291

listmail

Posts:291

danholme

Posts:94

listmail

Posts:291

04/23/2008 6:02 PM

LOL. Good show. I don't think my angle is strictly purist though, how about
security conscious versus administrative prettiness?

Some more comments because, well just because...

"o If you use the Group Policy to disable Allow Printers to be
Published, then the List in Directory option is not available, so even
local administrative users cannot publish printers"

Added caveat of - through this interface... (see loophole discussion)

"o The ONLY GROUPS THAT CAN CREATE PRINTER OBJECTS BY DEFAULT are the
following domain groups (not local): Administrators, Print Operators,
Account Operators and Enterprise Admins. Also the (domain controller)
System account. You can and should be managing the membership of these
domain level groups, else you must change the explicit permissions stamped
on each new computer object that give them Create Printer Object
permissions."

I added "by default", obviously implied but the ways around this are through
direct delegation as well as someone who is bright enough to create a
computer object with a specified SD or change the SD on a computer object to
say different. None of which is tricky, the key is being able to create or
modify a computer object which honestly isn't a high bar in the current
world of AD where we give out CREATE OU rights and not understand what level
of power that truly gives someone. Or even CREATE/MODIFY users which can be
a nightmare to Exchange. Every wake up with 10,000 users listed as having
mailboxes on the server you spec'ed for 3000? Did you give someone the
rights to modify/create users... lucky you, you caused your own issue.

"THEREFORE, BY DEFAULT, NON-ADMINSITRATIVE USERS WHO ARE NOT MEMBERS OF THE
ABOVE-LISTED GROUPS CANNOT CREATE PRINTERS."

Still a little nebulous here and too direct at the same time... (and
typo)... Question: Is a person with delegated rights to a computer object or
the ability to create a computer object or join a computer to AD an admin
user? You let me create my own computer account or you let me modify the SD
on a computer account and I can give Snoopy the right to create print queues
in AD.

"the printer object is created using the COMPUTERS CREDENTIALS (I confirmed
this). "

Yep as Brian mentioned earlier, the spooler should be doing this work
normally.

"Audit and punish. The reality is that hijacking the system account to
hack an object into your directory should be grounds for dismissal by any IT
security and usage policy."

Absolutely, but it could be too little too late. I do think "hijack" is a
bit rough of a term. It could be, but it doesn't necessarily have to be.
Running a scheduled job could be considered normal for instance, you knew it
would work, you didn't think it was a problem, why would IT leave you with
permissions to do something like that?? It again could also be that someone
specified a Security Descriptor when creating a computer object. Is that
against corporate policy? Could be, I think it would be unusual if it were
stated though, too many people and too many companies rest on the idea that
the default system is secure which is not something you can generally
assume.

To be honest, in the AD world I would say we have been more lucky than
"secure" over the years. There are various bad things that could have been
done all along but luckily the bad guys aren't looking our way for the most
part. However that doesn't mean it will always be the case. I always
recommend to be as secure as you can get yourself. I have yet to have been
in an environment that printers on personal PCs or MSMQ on personal PCs or
network routing stuff on personal PCs should be published to the directory
under computer objects. These are things that should normally be on servers.
In fact, in most cases where I have seen those is when someone goes to
delete a computer and don't realize they have subobjects and the delegation
doesn't give them delete tree rights... Then they complain to the DAs that
AD is broken. Admittedly I work in larger orgs (small would be around 30k
users I think), a smaller org may use personal PCs for print sharing or MSMQ
hosting or as routers...

Overall thanks for the chat Dan, I very much believe this kind of discussion
is good for the admins out there to read and see because it is not what they
see in the books that are out there, an honest full discussion of what is
going on and how it can be used against you. We have a very low bar for
admins in general in this world, I know, I work in a company that hires a
lot of them. They all need to know that there is a lot that they don't know
and discussions like this may or may not be new to them and it may or may
not get their thinking hats working a little bit more than they do when they
are pointing and clicking all day.

--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm

_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dan Holme
Sent: Wednesday, April 23, 2008 5:27 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Rights required to publish printer in AD

HERE WE GO!!! A definitive answer J

I was coming from the whats the business problem angle and Joe was coming
from the purist lockdown angle, both of which are correctjust different.
Here are the definitions from both sides (for whoever googles this in the
future):

The question was if we can lockdown the ability for user to publish
printers in AD.

If this is the real question: Every time a user (who is an a local
administrator) shares a printer and selects List In Directory, it gets
published to AD and is messy and problematic? then the simple answer is to
set as DISABLED the Allow Printers to be Published Group Policy setting,
scoped to the systems for which you do not want printers published. Along
the way, you should also get your users out of the Administrators group, but
that is a whole other thread ;-)

If the real question is how to authoritatively lock down the Create
Printer Objects permission, then you need to know the following:

HOW PRINTERS ARE CREATED FROM THE CLIENT UI

o Only LOCAL ADMINSITRATORS can share printers on XP & Vista. Therefore,
standard users can add printers locally (assuming driver is signed) but
can NOT share printer, therefore cannot publish printer to AD using Printer
Sharing UI.

o Users CANNOT create printer objects in AD by default by any means using
their own credentials (see last two bullets).

o If you use the Group Policy to disable Allow Printers to be Published,
then the List in Directory option is not available, so even local
administrative users cannot publish printers

HOW PRINTERS ARE CREATED DIRECTLY IN AD

o The ONLY GROUPS THAT CAN CREATE PRINTER OBJECTS are the following domain
groups (not local): Administrators, Print Operators, Account Operators and
Enterprise Admins. Also the (domain controller) System account. You can
and should be managing the membership of these domain level groups, else you
must change the explicit permissions stamped on each new computer object
that give them Create Printer Object permissions.

o THEREFORE, BY DEFAULT, NON-ADMINSITRATIVE USERS WHO ARE NOT MEMBERS OF
THE ABOVE-LISTED GROUPS CANNOT CREATE PRINTERS.

o HOWEVER, the SELF special identity has Create Printer Objects
permission on a computer object. That is why if a (local Admin) user
shares a printer, and chooses list in directory , the printer object is
created using the COMPUTERS CREDENTIALS (I confirmed this).

THE LOOPHOLE (discussed by Joe below)

o The only remaining loophole then would be if someone were to hijack
the system account to create a printer object in within the computers own
object in Active Directory (if they do this, you have MUCH bigger problems,
eh? J ). This is much harder now in Vista than it would have been in XP.
These are the options wisely put forth by Joe in the email below.

o To close this loophole, you need to either

§ Remove the Allow: Create Printer Objects permission from SELF (note
that self ALSO has Allow: Create All Child Objects so youd need to remove
that permission too and re-create any specific create child permissions you
do want). This would need to be done on every individual computer object.
OR

§ Set an *explicit deny* on *every* individual computer object:
Deny:SELF:Create Printer Objects. Note that an inherited OU ACE is not
sufficient, because there is an explicit allow stamped on each computer
object that will override. (EASIEST OPTION)
OR

§ Change the Schema default for Computer object so that the permissions are
exactly what you want. NOT RECOMMENDED
OR

§ Audit and punish. The reality is that hijacking the system account to
hack an object into your directory should be grounds for dismissal by any IT
security and usage policy.

I would suggest NOT closing the loophole (there are far too many issues
involved for it to be practical in most environments) and, instead, not
being purist and (if you are concerned) audit for the creation of Printer
Objects or the unauthorized hacking of and use of computer credentials.

Hope this helps!!!

Dan

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, April 23, 2008 9:42 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Rights required to publish printer in AD

I think we are addressing different concepts is all....

We are coming down to what do we mean by locked down... I see locked down in
a very strict security sense, not a "this is ok in the general case" sense.

Basically if you give me physical access to a machine that is a standard
type deployed machine in most of the world in a domain and I don't care what
GPO settings (in lieue of acls) you put into place I have high confidence I
can put printers (and other specific object types) in the directory under
that computer objects whether the admins want them there or not. This isn't
something everyone can do but using GPO certainly isn't "locking down" the
creation of printer objects by any security definition. It is simply a
matter of how much work is required based on how locked down the individual
member machine is. It could be trivial (i.e. a scheduled task) or it could
be more involved such as installing a service.

This solution may be "good enough"(tm) for the specific need stated by Neil
but no one should be under the misconception that it is a secure and
authoritative solution - i.e. no user could ever create a print queue object
in AD. To put it another way, it may be academic to Neil for this specific
case, but for the people who go googling later, it may not be academic for
them and they may read this as a secure way to lock something down.

Anyway, I wonder how many people even on this list that may think that this
is a true security solution (show of hands??). I may just go write a program
called "create printer objects for your shared printers or in actual fact
any printer you care to whether it exists or not even if your DA's don't
like it" just to futz with people who have deployed an environment and think
this is protecting them from anything but a GUI process.

On the bullet points...

I think the actual ACE is CRE/DEL child objects, I don't think it is focused
to printer objects but I didn't look lately. The simplest lightest weight
options would be to remove that ACE and remove ability to create any
subobjects (the safest choice) or to add the DENY CRE printer objects. The
other heavier solution (assuming this isn't just for one type of object)
would be to remove the CRE/DEL ACE and then add CRE/DEL for the specific
subobject types you want to allow creation for.

I agree on bullet two with the caveats above. If the idea is to prevent
someone following the normal process, this would do it. If you are looking
to truly lock down, this won't do it IMO. There are multiple ways to tell
the computer to publish those objects.

Further down

"USERS can NOT create printers in AD!!! " - do you truly believe that? I
feel that the user telling the computer to create the printer (regardless of
method and especially if you have disabled the auto-publish method) is
indeed the the user creating the printer. If you simply mean you cannot
contact the DC with a user security principal and create a printer under a
computer object, that is correct, but it is moot because the user has other
options as implied.

Again, only agree with this "then you will have had to specifically GIVE the
create object permission in order for anyone to be able to do it" in a
limited scope of above where the user's security credentials are handed to
AD to do the work.

"could theoretically" - theoretically, to you maybe..... ;o)

This all goes back to my root security standpoint - never assume that your
limitations are the same limitations others work with... Or more
specifically, never assume if you can't do something, someone else can't.
While an admin may not be able to figure out how to put something in the
directory through say the computer account, you can't guarantee and you can
never assume that someone using one of those computers can't or they aren't
running something that can.

Not being pedantic here as I don't believe this is trivial nor academic in
the generic form of the discussion. I am just very very specific about
security type items. I find all too often that people confuse what the GUI
or the supplied tools let them do with the actual security of the
environment. This GPO setting isn't security, it is adminstrative
assistance. I have seen huge long whining discussions of people who flipped
out when they found out that shares with $'s prepended on them aren't
actually truly hidden in the security sense, but only hidden from MSFT GUI's
for administrative ease reasons. You see someone say, yes, add a $ and it is
hidden and some nut job believes it and builds something that is supposed to
be secure on that concept and gets slapped around when someone walks up with
a list of their shares that they enumerated over the network including the
"secret" ones.

joe

--

O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm

_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dan Holme
Sent: Wednesday, April 23, 2008 1:40 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Rights required to publish printer in AD

Oh forgot to summarize the answer to the original question:

1) If you want to be ACL-focused, the answer is to remove all
permissions that allow Create Child Printer Objects on computers. (you
could deny as well, but you know)
BUT

2) The practical solution is to stop computers form creating printers:
thats the GP setting. Computers wont create printers if you tell them not
to.

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dan Holme
Sent: Wednesday, April 23, 2008 7:34 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Rights required to publish printer in AD

Guys, this is NOT THAT HARD!!!

The behavior is:

1) User (who is an admin on the computer) shares a printer

2) Computer publishes the printer to AD using the machines creds

USERS can NOT create printers in AD!!! There is no allow permission if
youve delegated systems correctly. So turning off Allow Printers to be
Published is keeping the COMPUTER from creating printers, which achieves
exactly what youre looking for.

You can and should manage who can create objects (printQueue objects in this
case) but as long as youve kept the big bad groups managed
(Administrators in the domain, Account Ops, Server Ops, Printer Ops) and
empty, then you will have had to specifically GIVE the create object
permission in order for anyone to be able to do it.

Final note: you need to watch how computer accounts are being created and
computers joined to the domain. It is possible that your permissions allow
the Create Object::printQueue permission on COMPUTERs as containers, in
which case someone (working very hard in the UI) could theoretically create
a printer in the Computer. But thats bad delegation of COMPTUERs in that
case, not of OUs or printQueues per se.

The real world scenario that the OP was addressing (proliferation of
unwanted printers) will be addressed by the policy.

Dan

Dan Holme

dan.holme@intelliem.com

www.intelliem.com

Phone: 415.670.9360 (finds me)

Land: 808.573.0726

Mobile: 602.295.1692

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Wednesday, April 23, 2008 6:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Rights required to publish printer in AD

This statement - "If you disable this setting, this computer's shared
printers cannot be published in Active Directory" - is incorrect.

It stops the GUI, it doesn't prevent the objects from being able to be put
in the directory.

--

O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm

_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brandon Shell
Sent: Wednesday, April 23, 2008 11:38 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Rights required to publish printer in AD

I am not talking about the auto creation... I am talking about the "Allow
Printers to be Published"

"Determines whether the computer's shared printers can be published in
Active Directory.

If you enable this setting or do not configure it, users can use the "List
in directory" option in the Printer's Properties' Sharing tab to publish
shared printers in Active Directory.

If you disable this setting, this computer's shared printers cannot be
published in Active Directory, and the "List in directory" option is not
available.

Note: This settings takes priority over the setting "Automatically publish
new printers in the Active Directory"."

But... I do agree with you. If the goal is TRULY lockdown then mod'ing AD
Permission is the only solution.

If security by obscurity is acceptable then setting "Allow Printers to be
Published" to Disabled would be effective.

On Wed, Apr 23, 2008 at 11:26 AM, joe <listmail@joeware.net> wrote:

Depends on what the real goal is.

If the goal is actually "lockdown the ability for user to publish printers
in AD" then the answer is no. If the goal is to make it so printers don't
automatically pop up in the directory, then yes.

Disabling auto publishing isn't locking anything down, it is preventing a
certain automatic function from occurring sort of like the reg key you can
set to prevent computers from changing their passwords. Lockdown has a very
specific meaning in the context of security. It doesn't mean prevent this
one method, it means prevent period.

For example, say you don't want people creating users. Is it enough to
prevent ADUC from displaying user as an object type they can instantiate?
Strictly speaking no, there are an unlimited number of other ways to go
about the work. If the idea is simply I don't want people creating users in
ADUC, sure it is enough.

Microsoft is actually semi-famous for doing security like that. Go back to
UMfD and look at the administrators group as a normal user. You couldn't do
it, but if you knew how to use net localgroup or had some other tool that
used the API for displaying local groups you could totally see the
membership. They did it again with hidden computer accounts or if you were
bright hidden user accounts in NT4, you append a $, the GUI won't display.
We saw that in Exchange 2000+ as well, everyone was running around thinking
you needed at least Exchange View rights to mailbox enable a user when in
fact all you needed was the ability to write two attributes on a user
object. You could drop me in an environment where I have no Exchange rights
but have rights to edit or create users and I expect I can make your
Exchange system run very poorly.

If the goal is to truly stop users from creating printer objects, unchecking
that check box does nothing to prevent that. I could sit down at a
workstation and create hundreds of thousands of printer objects unless there
was something else put into place to stop me.

joe

--

O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm

_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brandon Shell
Sent: Wednesday, April 23, 2008 10:19 AM

To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Rights required to publish printer in AD

If mod'ing the AD permission is not a good solution wouldn't using "Allow
Printers to be Published" set to disabled be the next best thing?

On Wed, Apr 23, 2008 at 10:08 AM, joe <listmail@joeware.net> wrote:

Turning that off doesn't "lockdown the ability for user to publish printers
in AD".

It just stops the automatic occurance of that happening.

--

O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm

_____

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dan Holme
Sent: Tuesday, April 22, 2008 3:34 PM

To: ActiveDir@mail.activedir.org

Subject: RE: [ActiveDir] Rights required to publish printer in AD

It's not that complicated! Turn off auto printer publishing on a GPO scoped
to the machines you are concerned about (i.e. the workstations). I'm *VERY*
confident it's done in the security context of the system b/c it's
"refreshed" automatically not just at initial sharing so it has nothing
to do with the user (except that the user has admin privileges on their
machine L allowing them to share a printer in the first place).

From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brandon Shell
Sent: Tuesday, April 22, 2008 9:26 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Rights required to publish printer in AD

Agree w/ Joe

Unknown Guy w/ Dean Ώ] (and temporarily allowed to be with joe ΐ])

Ώ] Cost Money

ΐ] Charity

On Tue, Apr 22, 2008 at 3:10 PM, joe <listmail@joeware.net> wrote:

In several companies I have seen this only as a problem with client OS
machines... I.E. Bob with his XP machine publishes a printer. No one had an
issue with servers publishing printers, it was workstations. So the solution
there is to have server machine accounts segregated from client computer
accounts and lock down creation of printer objects

Your Home Page ..

Site Articles:

Mail List Posts:

Friends

List Archives

List Archives