Windows Server

Gera · Guest

Design choice - to use one root domain and three child domains or to use
single domain and delegate some admin rights on OUs, all Windows 2003.

From your experience or simply opinion - what is easier and more safe:
1. to manage ACL on resources (root + child domains; top level admin from
root domain restricts some access to local admins in child domains using ACLs
on objects)
2. to manage a delegation on OUs (single domain with OUs which contain
regional domain's resources; root admin delegates needed rights through
Delegation Wizard)

I am interested from the point of users and resources adminstration, PC and
servers accounts managing,
and all other imaginable administrative activity. What couldn't be done in
the first or second scenario?
The concern... is it really possible to delegate absolutely any admin. need
using OU and Delegation Wizard?

Thanks a lot,
G.

ptwilliams · Guest

I'll just spout off the main bit of info relevant here - unless you have
absolute need to use four domains, you shouldn't. Law and security policy
(passwords, Kerberos) are the only real main reasons for new domains
(there's one or two others).

You can more or less delegate all control. (you can't delegate some of the
rights that a local power user has).

The delegation option will take a lot of planning and preparation, but will
be easier to manage in the end. Multiple domains requires more hardware and
more administration.

That ought to set this thread rolling ;-)

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

"Gera" <Gera@discussions.microsoft.com> wrote in message
news:3D8CE993-540E-4EFE-AEFE-27206640BBA8@microsoft.com...
Design choice - to use one root domain and three child domains or to use
single domain and delegate some admin rights on OUs, all Windows 2003.

From your experience or simply opinion - what is easier and more safe:
1. to manage ACL on resources (root + child domains; top level admin from
root domain restricts some access to local admins in child domains using
ACLs
on objects)
2. to manage a delegation on OUs (single domain with OUs which contain
regional domain's resources; root admin delegates needed rights through
Delegation Wizard)

I am interested from the point of users and resources adminstration, PC and
servers accounts managing,
and all other imaginable administrative activity. What couldn't be done in
the first or second scenario?
The concern... is it really possible to delegate absolutely any admin. need
using OU and Delegation Wizard?

Thanks a lot,
G.

Joe Richards [MVP] · Guest

First question: Who controls the forest? Those are the people who should get
domain admin rights and ability to log on domain controllers. No one else.

The people you are deciding whether they should have OU delegated permissions or
a child domain, do you mind if they control your entire forest?

Domains are not a security boundary, they are a policy boundary. If the intent
is to limit what people can manage, you only have the choice of separate forests
or delegated rights.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Gera wrote:

Gera · Guest

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:em$UFmC%23EHA.2180@TK2MSFTNGP12.phx.gbl...

Joe Richards [MVP] · Guest

Microsoft · Guest

That's very interesting. Could you outline how it is possible?
Is this legal and documented way or some type of vulnerability ?
What tools should be used?

G.

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:OywLZ7M%23EHA.3260@TK2MSFTNGP14.phx.gbl...

Gera · Guest

That's very interesting. Could you outline how it is possible?
Is this legal and documented way or some type of vulnerability ?
What tools should be used?

G.

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:OywLZ7M%23EHA.3260@TK2MSFTNGP14.phx.gbl...

Joe Richards [MVP] · Guest

I could but I won't. If you understand how AD works it is pretty obvious but I
will never post the details of it in a public forum so people don't get bright
ideas around it.

MS states very clearly now that the domain is NOT a security boundary, don't
ever think that it is. While it may contain you, it may not contain other people
who have access.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Gera wrote:

Gera · Guest

Well, Joe, looking at your site, I can tell that I really do not "understand
how AD works" like you,
though I am holding an MCSE/2000 ;-)

Ok, I fully agree that a domain isn't a security boundary, but could you at
least tell,
if this escalation done using official tools or in some another way,
manipulating SIDhistory and a like.
Could you write me personally at gera@lukrecija.lt, because I searched this
queston on MS site and on the Internet with no luck.

Thanks in advance,
--
Gera

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:e7ZmLaQ%23EHA.3820@TK2MSFTNGP11.phx.gbl...

Joe Richards [MVP] · Guest

Heh. I have been playing with AD in a huge enterprise environment (I deployed it
to a Fortune 5 company and operated it for ~4 years) for a long time. 4 years of
Windows AD in an enterprise is like 20 years in a smaller company. :o) Prior to
that I have ~4 years of Enterprise NT experience.

Once you have admin on a single DC, yes, you use normal supported processes to
compromise the rest of the forest. You don't have to do anything fancy. You only
have to be fancy if you have NO local logon access or system file access to DCs.
At that point depending on the type of access (network only or physical) you
have different possible vectors. A properly secured and patched DC should be
fairly safe if the only access is network only with no local logon or system
file access to a DC and passwords are intelligent and the network is secured
(i.e. not anyone can just plug in and see traffic to and from a DC).

Other than that, I won't get any more specific. MS isn't about to lay out the
details as well. Not sure if any other folks with the understanding are really
willing to publish either as we all have AD environments and would rather not
tell people specifically how to compromise them. :o)

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Gera wrote:

Gera · Guest

Ok, this amount of information is not bad either.
Especially the part that "MS isn't about to lay out the details as well."
;-)
Most of these recomendations will be used anyway.

By the way, _back to the topic_: from your 4 years of enterprise
environment,
was there some problems with Delegation of permissions?
Or you could assure that it possible to delegate any task in any scenario
(having a root-child forest) ?

--
Gera

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:u$Z9uTZ%23EHA.3708@TK2MSFTNGP14.phx.gbl...

Joe Richards [MVP] · Guest

We had a forest of 11 domains, ~250,000 users, ~150,000 contacts, ~2000 servers,
~400 domain controllers distributed around the world, ~100,000 groups, ~200,000
workstations, plus several hundred UNIX kerberized machines (this was growing,
should eventually get to about ~5000).

For all of this we had three (3) domain admin analysts, one (1) supervisor above
us who had domain admin access, the default admin ID's with random 20 character
passwords in envelopes in a high level manager's office that we couldn't get to
without the manager so it had to be bad - we never had to go get the IDs.

The domain admins were DA's of every domain and also Enterprise Admins.

Our delegation model worked very well. We wrote scripts to do most of the
delegation right off so it was done consistently. We were very tight on what we
allowed, the more flexibility you allow the harder the overall environment is
too manage. Many of the things a lot of folks say they need they don't really
need, it is just bells and whistles and things to make them feel cool.

All user modifications went through an inhouse built provisioning system, the
DA's and 3-4 user admins had native access to users and that was it. The user
admins tended to do everything through the provisioning system anyway, they
didn't use their delegated IDs.

Delegated rights were

1. Ability to join pre-created machine accounts for servers
2. Ability to modify description of servers
3. Ability to create and join machine accounts for workstations
4. Ability to modify membership and description of groups

Anything not delegated to local admins or that couldn't be done through the user
provisioning tool was a ticket sent to our support queue as a request. We would
verify the requests and then send the request into a script that did the work.

Overall the environment was one of the smoothest running AD environments I have
seen or heard about.

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Gera wrote:

Gera · Guest

Well, from all this I see that there are not much rights delegated to those
"very local" admins.
As far as I understood, probably not because it is difficult or impossible,
but because of "political" system of sending such tickets to your support
queue,
which consists of Domain Admin with full rights everywhere. It is also a
type of delegation, "delegation up" ;-)
Also ratio of users (and may be +contacts) to number of groups is
interesting. Or was there computer accounts grouped?...

I liked the idea of scripting delegation process, of course, in medium to
large env's.

What about passwords resets? Whom this task was delegated (or not) to?
Probably, to the provisioning system, and
I hope helpdesk wasn't those 3 admins.

--
Gera

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:evYCOsd%23EHA.3236@TK2MSFTNGP15.phx.gbl...

Joe Richards [MVP] · Guest

Password resets are handled by the user provisioning system or through an auto
system that we purchased from MTEC called PSYNCH. It allows password
resets/unlocks/changes to multiple environments based on RSA token, old
password, or Q&A profile through a web site. Initially I had a lot of issues
with them in how their stuff worked for various things like they couldn't work
with an ID that had basic delegated powers (useraccountcontrol, pwdLastSet, set
password, lockouttime) but I eventually beat them into shape. :o) Took about 18
additional months for their product to be launched but I refused to allow them
to launch without the product working properly.

The reason for the delegation model isn't political. It is for safety and change
control due to the lack of business rule logic in Active Directory. You can't
enforce naming standards or other standards through the directory so you either
need to proxy through some provisioning system (which I don't really consider AD
delegation) or pass the tickets to some other group who funnels all of the
requests and makes sure the rules are being followed. With the scripts the
scripts themselves follow the rules so the team with the power isn't even really
working it out, they are just trusted to always use the scripts. You can't say
that if you give them out to lots of people with rights, they may or may not use
them. If the group is small and in slapping distance, they will keep doing it.
Especially when they know they are ultimately responsible for the stuff being
right. When I left I was slowly working towards having a provisioning website
built that actually handled all of our requests that the user provisioning
system didn't handle. It was going slow because I was yanked into figuring out
the implementation of Exchange 2000. Had that not come up, I would have had it
completed before I left and the work could have been done by one person most
likely and that person would have been responsible for keeping the website
running and break/fix of AD.

As for the groups, the company uses a lot of shared data that can be accessed by
people all over the world and company but not necessarily whole divisions,
groups, departments. Role based security doesn't work very well in many
companies and ours was one of them as role based security is often admin'ed in
an 80/20 rule. If 80% of a group needs access to something, everyone gets that
access instead of having more security groups. We had too many financial and
other security rules we had to deal with to allow that much freedom to access to
data.

The project data structure is such that any owner with a top level shared folder
under a project share for a server will generally have at least two security
groups. One read-only access group and one read/write group. Some folders also
had additional permissions such as maybe ADD only access rights and some had
groups for subfolders under the top level folders say like you had a shared web
structure that you had people update and it got rolled up to a web server from
there.... so say you have a project server with say 100 top level folders for
various things. Then you have one of them as a web folder which has subfolders
for each group who publishes to the web site controlled by that web folder. You
would have a read-only group for all web authors to get into the top level web
folder and a read-write for the person who manages the whole structure and then
a read only and read-write group for each subfolder. A single project share on a
single server could easily eat up hundreds or thousands of groups on its own
depending on who was using it and how. Another server may have only 4-10 groups.
There were also groups used for grouping users together for the IM software we
used which was called, I think, SameTime.

The 3 domain admins were just that domain admins, 2/3 level support completely.
Global operation and our pagers would maybe go off after hours once every couple
of weeks and that is only for break/fix and usually because someone didn't
understand how the system worked or troubleshot it wrong. You could take all of
the group requests or subnet requests say for a whole day and do them all in a
few minutes with the scripts, that could be 10 groups or a 1000 groups. Didn't
really matter, the scripts just ran a wee bit slower. During initial migrations
into AD we were creating/importing thousands of groups a day every day while
doing our normal workload as well.

The help desk itself is huge and spread across the world and is actually handled
by another company for them. They have NO rights inside of AD other than normal
user rights so they can look at it. Since there aren't people dorking things up
all over the place with mistakes, you don't need a bunch of people that can run
around making changes to correct the mistakes.

The biggest downside to having only 3 people was around coverage when someone
was out for some reason. You have a dual pager system, primary and secondary
that way if the primary got shot or something, the secondary could fill in. It
was a pain when someone went on vacation or got sick or injured or as it started
occurring more and more before I left getting pulled off to consult for app
developers and integrators in the company so they used Active Directory
properly. During normal course of things the team regularly went out to lunch
together or some of them would go golfing (with the supervisor) during the day.
We could work from home or the office pretty much on the schedules we needed.
During the blackout (the main headquarters and our site was right in the middle
of all of that) we made our way down to the datacenter, checked out our stuff.
Anywhere in the world that had power was up and running fine (including our data
centers as we have massive generators that sound like locomotives). Any sites
that didn't have power we couldn't do anything about and anyway, they couldn't
use our stuff anyway. After the power came back, all of the replication kicked
back in and everything was back to normal. We didn't miss a single SLA for
break/fix nor new requests due to our redundancy and structuring.

AD is a great system because it is very flexible. The people get in trouble
though when they take that flexibibility and run it in an AD HOC way with little
or no controls and that simply isn't reasonable to do in a large enterprise.
Very tight change control and fixed ways of doing things (strict processes) are
required to have a supportable environment. The more out of control things get
the more power you have to start giving out to more people and the more out of
control it will get from there. The more people with power to make changes, the
more people with power to screw things up.

My perfect environment would be one where no users nor local admins have any
delegated write power in the directory at all and DA's rarely log on with their
DA account, usually just with their normal user account. Everything comes
through provisioning systems and has full business logic and logging applied to
it. It is possible to do with AD, just takes the intitial start up work to do it.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

Gera wrote:

Gera · Guest

Hm... this is probably the biggest reply in this newsgroup ever ;-)
And really overwhelming amount of information.
Thanks, Joe.

--
Gera

"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
news:%23l0xdfm%23EHA.2580@TK2MSFTNGP15.phx.gbl...

What is easier: to delegate or to use ACLs? Goto page 1, 2 Next

	Windows Server Forum Index -> Active Directory	All times are GMT Goto page 1, 2 Next
Page 1 of 2