Just for perspective, I can add another similar experience to Joe's. The difference was that the environment had >400 admins many of whom were unknown to those that should have known; add to that that DA was a fluid concept there. I had one admin (who wasn't supposed to be) brag about how he would do what he wanted by creating a new account, using it, and then deleting it to cover the tracks. I was there for Exchange, but because of the tight integration, the administrative model/mess was a vulnerability and my recommendation was to fix that prior to fixing anything with Exchange or any other application for that matter. It played out exactly as Joe predicts, only the body parts weren't discernible from the other gravel and plant debris when it was all said and done. Start the breathing. Stop the bleeding. Treat the wound. Check for shock (or cause it if needed) Rinse. Repeat. Works for carbon-based life as well as AD. In your case, it's already breathing and has a life of its own. You need to stop the bleeding before putting any life back into it else it will leak all over the place and create a much bigger mess. Great write up Joe. Gives a great insight into the thought process and how you've prioritized in the past. Al
________________________________
From: [EMAIL PROTECTED] on behalf of joe
Sent: Wed 9/7/2005 9:24 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] OU permissions for user object
My personal and professional opinion?
tick tick tick tick tick
tick tick click
boooooooooooooooooooooooooooooooooooooooooooooooom
You have a time bomb. Could be fine for a long time, could blow up entirely in
your face tomorrow leaving only scattered parts of hands and feet or things
that appear to possibly be part of hands and feet but in actually could be bits
of spleen and liver. The only thing I can say for sure, you have no clue what
you truly have in your directory and you have no control over the environment.
I understand that you didn't do this. The person willing to open up and say
they have an issue isn't *usually* the same person who came up with the idea or
likes the idea, that person sits behind a desk coverning up for the time the
bomb goes off never saying a word about it, if they realize at all that they
have built a bomb (or they already left). Sort of like the little dog that pees
on the carpet and looks around at everyone else seeming to say, "why did you
pee on the carpet?".
If I were brought into the situation and was told my job was to provide a
secure, stable, efficient environment. I would do the same thing I did for the
very very very large widget factory I used to work for and point this out to
management as insidiously evil and explain in great detail just how badly it
could hurt and how at that moment, you have no idea who has been reading what
files on any machines or reading whose mail (Assuming Exchange), or sending
mail as other users, and that any SLAs you have are almost certainly impossible
to guarantee because you have no/none/nada, control over the environment. I
would then say, if this is fine, I would appreciate a get out of jail free card
right now indicating you understand what I have said and that when something
goes down later due to this, I can pull that card out and say, look, you said
that you want it this way. If the manager truly understands what you are
saying, it is doubtful they will want things to stay the same. Basically, you
need management backing because people are not going to be happy as you back
out rights.
For the next step, I would yank every person's (that wasn't of the chosen 3 or
4 people) domain admin and server operator and any other excessive permissions
they had to DCs . We would then be working our butts off handling all of the
work being done by everyone else that supposedly needed domain admin. This
prevents the environment from changing unbeknownest you[1] and it teaches you
what is being done. It is a lot of extra work, but it helps you learn what is
being done and maybe some of the whys so you can come up with the proper
solutions. File and print can be done properly on DCs, I think it is a
horrendous idea and a great way to cause issues and reduce overall F&P
availability but it can be done. I would sooner throw file and print on a
little BSD box than put it on DCs, but there are times when you can't avoid it.
But you need to understand how it is being managed because the DAs own the DCs.
So now that you are handling all of that work, you spend a little time each day
working up the proper solution which involves either getting that crap onto
other machines or coming up with an effective way to manage it.
You obviously have the alternative of coming up with a solution first, but it
is a good chance you will miss something if you don't fully understand why
people need it. But maybe this is how you have to do it, at that point, forget
about the domain, focus on that solution. No use trying to make the domain
better since someone else can just tork it back up. Don't start making the
domain better until you have control of it otherwise it will take you forever
to get anything done.
Any time there was something that I felt was wrong and was too much power to
give out on DCs or in AD, instead of simply saying no, if the function was
truly critical (versus one person's idea of critical) I always offered an
alternative even if the alternative was, take on extra work until I can find a
better way. Take, for instance, the EMC Celarra POS boxes. They required domain
admin to properly add them to the domain, I fought like cats and dogs to make
it so they weren't added to production until that part (and many other things)
was corrected. I and the others fighting it were overruled. Instead of giving
out domain admin rights, my manager said fine, "if someone wants one added,
they come to me and I add them. No one else.". "But that's a bottle neck or
what if you aren't here?", response... tough, these shouldn't be going into the
production environment anyway because they are half-ass.
In general, it was far more important to me to keep things locked down than not
take on extra work, I would rather work 80 hours a week because I choose it
than give out permissions that cause me to work 80 hours a week because I have
to hold the environment together. Giving out rights to dork up the environment
and then trying to maintain and control that same environment is sort of like
wrangling jello with chopsticks. Pointless and impossible. Anyone who gives out
excessive rights on the domains and domain controllers but guarantees security
or an SLA or SLO for the environment really can't guarantee it, they are just
getting lucky. I have very base core issues with telling someone I guarantee
something if I know I can't.
One last item, Serv Ops only exists on DCs. They don't exist on members.
joe
[1] One quick story from the widget factory prior to when I was able to wrestle
DA from everyone. The company was global, presence in probably every TZ in the
world. Some of the folks who had DA rights lived in Europe. I would correct
things during after hours US time because that is when I had time. Magically
when I came in the next morning, one or more changes would have occurred
switching some stuff back and other bad things being done. I finally chased it
down to European admins who were "fixing" settings during their business hours.
That gave me the ammo to remove the final additional admins and after that the
environment didn't mysteriously change on me on a daily basis. I was able to
quickly make it far more stable and robust without it all being undone.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Abagnale
Sent: Wednesday, September 07, 2005 5:21 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] OU permissions for user object
Historically before I joined, Every new member to IT was made a member of the
Domain Admins group, it's a bad legacy from NT4 and no one ever really thought
out a proper approach to deploying AD, it was a case of put AD in and think
about the rest later. Well that later never came to anything because like most
things it just dragged on and on and before you know it, the business grows,
other systems have been bolted onto AD and the processes that have been put in
place require the IT member to have domain admin privilege ( or so they think
they do).
The biggest issue is we have over 80 DC's which act as File & Print Servers at
remote branch sites spread over the country and the processes the Service Desk
Manager currently has in place require members of the Service Desk to access
these F&P's to carry out work such as Profile & Data moves. I know this can be
done without having to logon to the servers, however, retraining and processes
would need to be re-written for these staff members to follow (according to the
Service Desk Manager). This is not going to happen over night, throw in the
politics surrounding and it becomes a battle.
I have delegated new AD permissions to the Service Desk group which they are
happy with, so the AD permissions are sorted, they just want to have access to
logon to the Remote F&P's which as they are DCs and the type of work they are
doing currently, I could only see Server Operators (or Print Operators) as an
option.
The overall goal, is to reduce the number of Domain Admins from over 100 to 8
but Service Desk must still be able to logon to the remote file & print servers
(which are DC's).
Any ideas welcome, I may have missed out other points, but that's the basis.
"Grillenmeier, Guido" <[EMAIL PROTECTED]> wrote:
> however this is managements call.
and what do you do if your management tells you to shoot you in your
foot? I'd certainly talk to your management and ask the rational behind
their demand. Ideally no user should be a member of the builtin Server
Operators group of the domain at all (no problem with Server OPs on member
servers). There is a reason why members of this group (and many other built-in
groups) are protected by the AdminSDholder process => they are very sensitive
accounts so that normal delegation task (such as resetting PW etc.) should not
be granted on these accounts. Ofcourse you can change this "protection"
behaviour in AD, but this doesn't make any sense unless you are willing to risk
your company's assets.
So you better try to find what their overall goal is, then we can help
you figure out the best way to grant the correct permissions in a way that will
work well with the delegation concept of AD.
/Guido
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank
Abagnale
Sent: Freitag, 2. September 2005 08:34
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] OU permissions for user object
Hi Guido,
Yes you are correct, this is what is happening. But I believe the
reason that the inherit on existing objects is not checked is due to the
adminsdholder. The user is question is a member of the builtin\server operators
group, therefore when I set the user object to inherit the permissions, it
resets itself to unchecked after roughly 15mins.
I now have a problem, my global group I which I have delegated
permissions to on an OU must be a member of the Builtin\Server Operators group.
If the inherit flag is reset after 10mins, how can I get this user object to be
able to administer other users who are also members of the Builtin\Server
Operators group?
If I had the choice, I wouldn't use the builtin groups, however this is
managements call.
thanks
"Grillenmeier, Guido" <[EMAIL PROTECTED]> wrote:
sounds to me as if you've not set the permission to _inherit_
down to existing objects - check in the Advanced tab of the security editor
(the tab that displays the permissions on your OU in ADUC) and see if your Full
Control permission are set for User Objects (which will then automatically
inherit down to user objects within this OU). If you've set the permission to
all object, you'll explicitely have to set the scope of the permission to apply
to "This object and all child objects" (or just to the child objects) - this
will then inherit the permission to objects within the OU.
/Guido
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Frank Abagnale
Sent: Donnerstag, 25. August 2005 10:46
To: Active
Subject: [ActiveDir] OU permissions for user object
Hi,
I've created an OU and I have delegated a security group the
Create/Delete User Object with Full Permissions.
I have also delegated the 'Create, Delete & Manage User
Account' right with F/C
I only want this security group to be able to manage user
accounts in this OU and modify the users details/group membership.
The problem I have is that I can't enable/disable a user or
modify the user's details on an account which already exists.
If I create a new account, I can do all the delegated tasks
set, but on existing accounts I get error messages such as "you have
insufficient rights to perform this operation" or the details are greyed out.
Any idea's where I can check?
Iain
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
________________________________
Start your day with Yahoo! - make it your home page
<http://us.rd.yahoo.com/evt=34442/*http://www.yahoo.com/r/hs>
________________________________
Click here to donate to the Hurricane Katrina relief effort.
<http://store.yahoo.com/redcross-donate3/>
<<winmail.dat>>
