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 objectHi 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 objectHi,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/CI 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
Click here to donate to the Hurricane Katrina relief effort.
