| Author | Messages | |
abagnale_lists
Posts:16
 | | 08/25/2005 8:46 AM |
| 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 | | | |
| josemedeiros
Posts:0
| | 08/25/2005 8:51 AM |
| I may be mistaken, but it sounds to me like you
need to recursively reset the permissions of the existing objects within
that OU.
Jose
----- Original Message -----
From:
Frank
Abagnale
To: Active
Sent: Thursday, August 25, 2005 1:45
AM
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 | | | |
| abagnale_lists
Posts:16
| | 08/25/2005 9:18 AM |
| I may be mistaken, but it sounds to me like you need to recursively reset the permissions of the existing objects within that OU.
Jose
----- Original Message -----
From: Frank Abagnale
To: Active
Sent: Thursday, August 25, 2005 1:45 AM
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 __________________________________________________Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com | | | |
| GuidoG
Posts:113
| | 08/27/2005 10:16 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank
AbagnaleSent: Donnerstag, 25. August 2005 10:46To:
ActiveSubject: [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 | | | |
| abagnale_lists
Posts:16
| | 09/02/2005 6:36 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank AbagnaleSent: Donnerstag, 25. August 2005 10:46To: ActiveSubject: [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 | | | |
| GuidoG
Posts:113
| | 09/06/2005 7:35 AM |
| > 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank
AbagnaleSent: Freitag, 2. September 2005 08:34To:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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"
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank
AbagnaleSent: Donnerstag, 25. August 2005 10:46To:
ActiveSubject: [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 | | | |
| listmail
Posts:822
| | 09/07/2005 1:33 AM |
| 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Ώ]
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
Ώ] 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank
AbagnaleSent: Wednesday, September 07, 2005 5:21 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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"
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank
AbagnaleSent: Freitag, 2. September 2005 08:34To:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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"
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank
AbagnaleSent: Donnerstag, 25. August 2005 10:46To:
ActiveSubject: [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
Click here to donate to the
Hurricane Katrina relief effort. | | | |
| Glen@xxxx.yyy
| | 09/07/2005 1:45 AM |
| Joe! Great story! Consider a book!
PS I really like the spleen thing cause your
right you never really can tell.
-----Original Message-----
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Wednesday,
September 07, 2005 8:24 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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Ώ] 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
Ώ] 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Frank Abagnale
Sent: Wednesday, September 07,
2005 5:21 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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" 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Frank Abagnale
Sent: Freitag, 2. September 2005
08:34
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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" 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] 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
Click
here to donate to the Hurricane Katrina relief effort.
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ | | | |
| CreamerM@xxxx.yyy
| | 09/07/2005 1:57 AM |
| Hehe¦where else can you get some
much information *and*
entertainment in one place!
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Wednesday, September 07,
2005 9:24 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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Ώ] 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
Ώ] 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank Abagnale
Sent: Wednesday, September 07,
2005 5:21 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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" 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank Abagnale
Sent: Freitag, 2. September 2005
08:34
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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" 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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] 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
Click here to donate
to the Hurricane Katrina relief effort.
This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated. | | | |
| Alm@xxxx.yyy
| | 09/07/2005 2:35 AM |
| ________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of joe
Sent: Wed 9/7/2005 9:24 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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Ώ] 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
Ώ] 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank Abagnale
Sent: Wednesday, September 07, 2005 5:21 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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" 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank Abagnale
Sent: Freitag, 2. September 2005 08:34
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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" 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] 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
________________________________
Click here to donate to the Hurricane Katrina relief effort.
> | | | |
| laurahcomputing
Posts:148
| | 09/07/2005 5:44 AM |
| 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.
As joe-isms go, I think that one just became my favourite, and one to live by.
Laura
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ | | | |
| abagnale_lists
Posts:16
| | 09/07/2005 9:22 AM |
| 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" 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank AbagnaleSent: Freitag, 2. September 2005 08:34To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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" 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Frank AbagnaleSent: Donnerstag, 25. August 2005 10:46To: ActiveSubject: [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
Click here to donate to the Hurricane Katrina relief effort. | | | |
|
|