| Author | Messages | |
peng.beitian
Posts:1
 | | 04/26/2008 2:26 AM |
| I found the readme.txt (included below) file at the following link:
http://rapidshare.com/files/110472699/scprogue.zip.html
I tried scp rogue in a test forest and it worked as described. Is the advice to change object security for desktop computers computers to remove SELF "Create all child
objects" and to "Delete all child objects" a good idea?
I am sorry if this topic has already been discussed, If so, please point me to the right place in the archives...
===========================
Release notes for scprogue
===========================
Today I noticed that the default security descriptor for computer objects created when joining workstations allows SELF to "Create all child objects" and to "Delete all child objects".
This got me thinking about the types of things that someone with physical or local admin access to a machine that is joined to Active Directory might be able to do...
As most AD administrators know, the "computer" object class is alsoa container that may posses several types of objects object classes. One of these allowed computer child classes is the seamingly benign ServiceConnectionPoint (SCP) class.
ServiceConnectionPoints may contain the keywords and serviceBindingInformation attibutes. Both of these are indexed, and members of the partial attribute set (in other words, they are replicated to all global catalog servers) -- making creation of serviceConnectionPoint something that generates forest wide
replication trafic.
scprogue is a (very clunky) application that demonstrates how any local admin desktop user can create (LOTS) of service connection points in Active Directory using the security context of computer's own AD account. scprogue isn't special in any way. In fact it's mostly cut-n-pasted code from various MSDN samples.
ANY application capable of running as LocalSystem or NetworkSystem would be able to do exactly what scprogue can do.
One way to avoid allowing a program like 'scprogue' to fill Active Directory with SCP objects is rule your desktops with an iron fist (i.e. absolutely NO local administrator access). Unfortunately this kind of control can be extemely difficult to maintain -- especially for machines where physical access is allowed.
Fortunately, I think there is a much easier way: Simply remove "Create all child objects" and to "Delete all child objects" permissions for SELF on computer objects representing desktop workstations. DO NOT remove "Create all child objects" and to "Delete all child objects" for servers that you (the AD Admin
have good physical and administrative control over) as the ability to create and maintain legitimate ServiceConnectionPoints is important (and extremely useful) functionality for some services that you might want to install on your managed servers.
... I wonder if Microsoft would please consider making a KB article available that does a better job (than this document does) of educating people about how to avoid: "SELF creation of service connection points in Active Directory by member workstations". Even better, Is it a good idea to change the default security descriptor so that SELF "Create all child objects" and to "
Delete all child objects" must be explicitly enabled.
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
| | | |
| dmitrig
Posts:59
| | 04/26/2008 10:44 AM |
| You can remove CreateChild permission, but it might break applications that rely on this permission being present. ADAM is one of the apps that register SCPs - it won't be truly broken, but it will complain about this. Other apps may take this more seriously.
Another option is implementing AD quotas for non-privileged accounts. This is a fairly unexplored area unfortunately, but it was developed in w2k3 for exactly this purpose.
Dmitri
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of John Doe
Sent: Saturday, April 26, 2008 12:21 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Should I be worried by this?
I found the readme.txt (included below) file at the following link:
http://rapidshare.com/files/110472699/scprogue.zip.html
I tried scp rogue in a test forest and it worked as described. Is the advice to change object security for desktop computers computers to remove SELF "Create all child
objects" and to "Delete all child objects" a good idea?
I am sorry if this topic has already been discussed, If so, please point me to the right place in the archives...
===========================
Release notes for scprogue
===========================
Today I noticed that the default security descriptor for computer objects created when joining workstations allows SELF to "Create all child objects" and to "Delete all child objects".
This got me thinking about the types of things that someone with physical or local admin access to a machine that is joined to Active Directory might be able to do...
As most AD administrators know, the "computer" object class is alsoa container that may posses several types of objects object classes. One of these allowed computer child classes is the seamingly benign ServiceConnectionPoint (SCP) class.
ServiceConnectionPoints may contain the keywords and serviceBindingInformation attibutes. Both of these are indexed, and members of the partial attribute set (in other words, they are replicated to all global catalog servers) -- making creation of serviceConnectionPoint something that generates forest wide
replication trafic.
scprogue is a (very clunky) application that demonstrates how any local admin desktop user can create (LOTS) of service connection points in Active Directory using the security context of computer's own AD account. scprogue isn't special in any way. In fact it's mostly cut-n-pasted code from various MSDN samples.
ANY application capable of running as LocalSystem or NetworkSystem would be able to do exactly what scprogue can do.
One way to avoid allowing a program like 'scprogue' to fill Active Directory with SCP objects is rule your desktops with an iron fist (i.e. absolutely NO local administrator access). Unfortunately this kind of control can be extemely difficult to maintain -- especially for machines where physical access is allowed.
Fortunately, I think there is a much easier way: Simply remove "Create all child objects" and to "Delete all child objects" permissions for SELF on computer objects representing desktop workstations. DO NOT remove "Create all child objects" and to "Delete all child objects" for servers that you (the AD Admin
have good physical and administrative control over) as the ability to create and maintain legitimate ServiceConnectionPoints is important (and extremely useful) functionality for some services that you might want to install on your managed servers.
... I wonder if Microsoft would please consider making a KB article available that does a better job (than this document does) of educating people about how to avoid: "SELF creation of service connection points in Active Directory by member workstations". Even better, Is it a good idea to change the default security descriptor so that SELF "Create all child objects" and to "
Delete all child objects" must be explicitly enabled.
________________________________
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.<http://us.rd.yahoo.com/evt=51733/*http:/mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ%20>
| | | |
| listmail
Posts:326
| | 04/26/2008 12:05 PM |
| There was a whole conversation on this basic point the last few days, look
for the thread on rights to publish printers; primarily the back and forth
responses between Dan Holme and myself at the end of the thread.
Ok I meant to have a short response here with some general stuff but found I
started rambling... So if you want to read on, I expect there is some
interesting info in here for some of you. If not, no skin off my nose, I
like that I documented some thoughts here that I have done or thought of
that I never documented otherwise... 
Trying to rule your desktops with an "iron fist" is one way to attempt this
but is in no way guaranteed. It is the whole argument about using front end
rules to protect your back end, it just isn't comprehensive enough for those
who are truly security minded and concerned. You protect the backend at the
backend and if you want, in addition at the front end. If you are an app dev
it is similar to only doing data validation at your primary input interface
and not anywhere where data goes out of your hands and comes back to you
(like for instance if the data goes into a store that you don't fully
control which could be SQL or AD or whateverΏ]).
So the secure way to clean this up is to use ACLs on the AD objects or as
Dmitri mentioned, AD Object Quotas. My thoughts on this are look at the
various computer objects, should they be publishing anything? On servers the
answer is almost always absolutely. On workstations... maybe, depends on
your company. Do you allow people to publish MSMQ objects or print queues or
SCPs for workstations? Up to the company. So for servers you maybe allow
that right to remain, create/del child objects all day and with
workstations, maybe you want to do it in a select way, to me that means lock
it all down and open up just what you need (maybe print queue objects) or
lock it all down on those machines and use a proxy tool to create the
objects (for example Active Roles Server allows you to create print queue
objects) or maybe you take away the rights entirely.
There is nothing new here... This has been a concern since the release of
AD. I recall having a pretty deep email conversation with a large
manufacturer I was with about this very topic back in 2000/2001 time frame
after I started really digging into the security model.
One the issues is that there is no easy separator between what is a server
and what is a workstation in AD. They are both simply computer accounts. I
mentioned to our TAM back in the 2000 time frame that I thought that was a
bit short sighted. Forgot about it after that as I came up with various
mechanisms to deal with it. One is you can look at the operatingSystem
attribute and work out which are client OS and server OS levels. You can
keep the machines segregated into their own specific OUs (i.e. no
workstations in Server OUs and vice versa) and then parse out the parentage.
You can add an additional attribute to computer objects that flags in some
way whether a machine is a server or a client (could be boolean or string or
integer or whatever really.... its for you) or you could add all servers to
a specific group that is the "server OS" group. You could add an aux class
to AD that is to be tied to Server objects or workstation objects. I have
done on a couple of occasions the attribute joeware-ServerClass and
joeware-WSClass and it adds a couple of attribs that I need only for server
or client objects (or maybe I didn't need any extra attributes, I just
wanted the class attached to the objects) and then dynamically add the class
to the server objects. You can also do that for Windows wannabee machines
like SAMBA or NAS devices which pretend to be Windows or UNIX machines that
are joined for kerberos (e.g. prefix-SAMBAClass, prefix-NASClass) etc...
These help you find ways to quickly segregate out the machines though only
the operatingSystem is enforced though with the addition of trademark
symbols into that fieldΐ] it makes it a little more painful for doing
things with that field.
Maybe you read the above about adding an aux class that doesn't add any
attributes and you ask... why go through all the trouble of defining an aux
class and applying it to computer objects if you don't have any extra
attributes to add??? Anyone asking that question? First is of course being
able to search for the objects as mentioned above... Especially if you have
indexed objectclass (or are running Windows Server 2008 which indexes
objectclass whether you want it or not)... But what about ACLs... You can
now specify that objectclass in an ACE and grant inheritable permissions
that way... Maybe take away create/delete child from the
defaultsecuritydescriptor for computers and grant it back at the top of the
branch that holds server objects (or server and workstation as this will
filter automatically) a GRANT CRE/DEL to SELF and then add the aux class to
all of the servers you want to have that permission and then wipe that
explicit SELF CRE/DEL permissions on all computer objects... Maybe you set
up a class instead that is prefix-AddSCPs and then at the root do a grant of
CRE/DEL SCPs for SELF to that class... I am not sure if I would get that
granular like that, I would rather try to do CRE/DEL CHILD period unless it
was simply one or two specific classes you wanted to grant.
Couple of notes on that
1. Be careful about bloating your ACLs. I hate going into environments and
seeing a DSACLS dump that goes for 5-10-20-30 pages... You are likely
getting a bit over complicated if you see that. I had one company that we
cleaned up the ACLs for and literally a script I have that does an Exchange
object data validation audit which dumps all mailbox and mail enabled
objects in a forest went from taking over 2 hours to dump every object to
taking just over one 1 hour... just from cleaning the ACLs up. If you are
ACLing things that much, you may instead want to look at some sort of Proxy
Admin tool... I will mention Active Roles Server again. Quest should be
tossing me money for these shout outs (you listening Bob?)... But any
tool that abstracts the permissions away from AD Objects and keeps them in a
separate store and hopefully also provides business rules is a good thing
(tm) if you are doing a lot of permissioning. Yes yes I know, it can be
expensive and complicated and difficult to set up with all of the extra DB
requirements etcΑ]... But it can be immensely worth it as well.
2. Remember that anyone who creates an objects can set their own SD when
they create it so they can override what you did. And if they are the owner
they can also change the SD after the fact... This is mitigated in Windows
Server 2008 with the new Owner stuff. See
http://www.open-a-socket.com/?p=18, very well written good article except
for caving into MS Marketing and calling Active Directory ADDS.... It is AD
and it is ADAMΒ].
For something like this, I would set those perms up and then I would have
some sort of spider tool that constantly scanned for objects that should
have that objectclass or shouldn't have that objectclass and clean them up
as necessary. Sort of what a lot of companies do now with the ownership of
objects where they look for any objects that have an owner of something
other than say DsOwner or some other ID they created that they wanted
everything to be owned by so they didn't have to worry about the way
overpowerful owner perms on objects. Of course the fun part is identifying
these objects which is what this is all about in the first place. If it is
simply about the OS, you can mostly handle that by looking at
operatingSystem and just write the code once for making that determination
instead of in every app that needs to ascertain the difference and it can be
"done right" (again (tm)) that way and updated in one place as new OS'es
come out.
Ok so enough rambling... I better put a ramble alert at the top of this...
joe
Ώ] See Exchange for stellar examples of this... They often expect
everything in AD will be perfect for them which is a huge poor assumption
because they don't control that store so when info comes into Exchange that
didn't go through ESM or ADUC it isn't validated and if anything is wrong
with that data, Exchange has no clue until it crashes or otherwise operates
incorrectly.
ΐ] Although I bugged the hell out of this and fought it tooth and nail in
the Vista Beta and didn't win but was told it would likely be fixed for
Longhorn... It was, they used the Registered symbol instead... great... How
about the people doing that stuff at MSFT actually try using command line
tools some time... If I was a tester at MSFT I would have bounced the OS for
that alone. Now it will probably have to come down to an AD side fix that
cleans that field up to be Windows Vista (tm) Ultimate instead of Windows
VistaT Ultimate... How do you enter T in a command line LDAP query???
Especially when you are whipping through typing quickly. Hmmm note to self,
add some sort of way to do that in AdFindΒ].
Α] Does anyone out there make a tool that does proxy delegation work
against AD that doesn't require SQL Server, SharePoint, or any of the other
application services that you have to maintain separately from the proxy
delegation tool itself? If so, let me know, I would like to look at it and
if I like it, I will push it. I hate any infrastructure apps that have
requirements on what I feel is application technology such as SQL Server and
Sharepoint. This goes for yes... MOM and MIIS/ILM as well. ESE is a
perfectly good DB as is proven in millions of instances around the world. It
may be more difficult to work with it but managing and upgrading your DB
outside of the application isn't a problem and you aren't worried about ESE
versions, etc. The idea I can't upgrade my infrastructure management tool
because I have the wrong version of the OS or I can't upgrade a DB because
the infrastructure management tool will break just irks me to no end.
Non-infrastructure apps can use that stuff all day but anything needed to
run my core level OS stuff, I want to be based on core level OS stuff. Oh
while I am at it... Outlook should be using ESE as well; not that PST and
OST crap.
Β] Lets all send a collective middle finger up message to MS Marketing
with the whole ADDS and ADLDS crap and just everyone continue saying AD and
ADAM. As well as the TM and R in the operating system names registered in
AD. 
--
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 John Doe
Sent: Saturday, April 26, 2008 2:21 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Should I be worried by this?
I found the readme.txt (included below) file at the following link:
http://rapidshare.com/files/110472699/scprogue.zip.html
I tried scp rogue in a test forest and it worked as described. Is the
advice to change object security for desktop computers computers to remove
SELF "Create all child
objects" and to "Delete all child objects" a good idea?
I am sorry if this topic has already been discussed, If so, please point me
to the right place in the archives...
===========================
Release notes for scprogue
===========================
Today I noticed that the default security descriptor for computer objects
created when joining workstations allows SELF to "Create all child objects"
and to "Delete all child objects".
This got me thinking about the types of things that someone with physical or
local admin access to a machine that is joined to Active Directory might be
able to do...
As most AD administrators know, the "computer" object class is alsoa
container that may posses several types of objects object classes. One of
these allowed computer child classes is the seamingly benign
ServiceConnectionPoint (SCP) class.
ServiceConnectionPoints may contain the keywords and
serviceBindingInformation attibutes. Both of these are indexed, and members
of the partial attribute set (in other words, they are replicated to all
global catalog servers) -- making creation of serviceConnectionPoint
something that generates forest wide
replication trafic.
scprogue is a (very clunky) application that demonstrates how any local
admin desktop user can create (LOTS) of service connection points in Active
Directory using the security context of computer's own AD account. scprogue
isn't special in any way. In fact it's mostly cut-n-pasted code from
various MSDN samples.
ANY application capable of running as LocalSystem or NetworkSystem would be
able to do exactly what scprogue can do.
One way to avoid allowing a program like 'scprogue' to fill Active Directory
with SCP objects is rule your desktops with an iron fist (i.e. absolutely NO
local administrator access). Unfortunately this kind of control can be
extemely difficult to maintain -- especially for machines where physical
access is allowed.
Fortunately, I think there is a much easier way: Simply remove "Create all
child objects" and to "Delete all child objects" permissions for SELF on
computer objects representing desktop workstations. DO NOT remove "Create
all child objects" and to "Delete all child objects" for servers that you
(the AD Admin
have good physical and administrative control over) as the ability to create
and maintain legitimate ServiceConnectionPoints is important (and extremely
useful) functionality for some services that you might want to install on
your managed servers.
... I wonder if Microsoft would please consider making a KB article
available that does a better job (than this document does) of educating
people about how to avoid: "SELF creation of service connection points in
Active Directory by member workstations". Even better, Is it a good idea to
change the default security descriptor so that SELF "Create all child
objects" and to "
Delete all child objects" must be explicitly enabled.
_____
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try
<http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8
HDtDypao8Wcj9tAcJ> it now.
| | | |
|
|