Questions

Delegation and Inheritance

+
1 Votes
Locked

Delegation and Inheritance

Curt
Reposting as I posted in the wrong forum first time (sorry about the duplication).
Edit: Used the term "OU" where I should have used the term "group" when referring to the "Help Desk" item.

I'm delving into MS Active Directory for the first time, and I've run into a road block regarding how delegation and inheritance mix. I'm reading the 70-640 Microsoft book for anyone that wants to follow along. I've already posted into a MS forum, so for efficiency, I'll just copy/paste:

Part1--------------------
Hi all. I have what is likely a very simple question, but as I'm just starting out, nothing is obvious.

I'm reading the 70-640 book on Active Directory and I'm trying to understand how ACEs applied to groups really work. I think the best way to ask my question is by example. I'm on pp 78 (Ch 2, Lsn 3, Ex 1) and I'm delegating the "reset password" ACE to the "Help Desk" group, so Barbara Mayer, being a member of the "Help Desk" group can now reset passwords. That's great.

So I'm thinking, from now on, all my help desk employees are going to be able to reset passwords, which sounds good to me, so I add Dan Holmes to the group "Help Desk", check his effective permissions, and Dan can't reset passwords !?! What did I just miss?

At this point I'm thinking I have to keep a spread sheet of every ACE I apply to every group so that I can reapply those ACEs to new members of groups which seems totally crazy so I know I missing something here. Can someone please explain what I'm not understanding? Thanks.

Part 2 -------------------------------
I've made it to the end of Chapter 2, and I think I understand what's going on, but it still doesn't seem reasonable. When I started, I thought I was giving users in the "Help Desk" group the permission to reset other users passwords (which is apparently wrong). Now, it appears to me that I was actually giving users the privilege of having their password changed by someone currently in the Help Desk group. So if I add a new user, I can automatically know that existing Help Desk group members will be able to change the new users password, but if I add somone to the the Help Desk group, that new member of the Help Desk group will not be able to change any users passwords regardless of when I add them. This still seems really strange.... so now I need to keep track of what ACE I've applied to what group, and reapply the ACE using the ACE Wizzard each time I make a user part of an existing group. This is totally crazy!!!

-----------------------------
Can someone show me where I'm going wrong? Thanks in advance.
  • +
    1 Votes
    seanferd

    but I've always been under the impression that policies applied to Groups and Users, not OUs. So, following this possibly completely wrong understanding, you would have a Help Desk Group which is allowed the pwd rst permissions, and adding Dan to this group would give him these permissions as well (allowing that you did not specify that Dan as a User does not have this permission).

    +
    2 Votes
    Curt

    I think you're right about the ACE being applied to the Group and not to the OU. Not sure why I called the Help Desk group an OU in my previous question, because it's not an OU, and that's not my intention. With that out of the way, what you say would make sense, except, when I add Dan to the Help Desk group, Dan can't reset passwords.

    ---------------------

    Just went back and re-read and now I know why I used "OU" terminology instead of the "Group" term. The ACE is applied to the OU, not the group. Also, I think I've answered my question that I started out with. If I add Dan Holme to the Help Desk group, he can reset passwords, if I log off as the administrator, and login as Barbara, log out as Barbara, log in as Admin, log out as Admin, and log in as Dan (ya... that was stupid, but I doesn't work unless I log out and in a bunch of times.... 3 seems to be the magic number; after that the "reset password" ace appears in the ACL for Dan and he can reset passwords; before the multi login/logout, the ACE does not appear in the ACL and Dan can't reset passwords @#$^%^#/????

    ---------------

    Noticed that inheritance was turned off for all my users. Not sure how as new users have inheritance on by default. After turning inheritance back on for all users and doing the login/logout dance a few times, everything is working and people that I add to the "Help Desk" group are instantly showing the ACE in effective permissions.

    +
    0 Votes
    seanferd

    OK then, I'm out. See the replies from professionals with experience below. Good luck!

    +
    2 Votes
    OriginalM

    If you add a user to a group with the proper rights the user is needing to do something on a file share or in AD. The user itself must do a logoff - logon to get the rights assigned to its account.

    If you have multiple DC's it could take up to xx minutes - depending on server replication - before the rights are replicated to its account on its logon server.

    +
    2 Votes
    CG IT

    you said:

    I've made it to the end of Chapter 2, and I think I understand what's going on, but it still doesn't seem reasonable.

    What is reasonable to you isn't necessarily reasonable to Microsoft. you really have to look at it in a security context rather than what is easiest to do or what would be reasonable to you.

    When I started, I thought I was giving users in the "Help Desk" group the permission to reset other users passwords (which is apparently wrong). Now, it appears to me that I was actually giving users the privilege of having their password changed by someone currently in the Help Desk group. So if I add a new user, I can automatically know that existing Help Desk group members will be able to change the new users password, but if I add somone to the the Help Desk group, that new member of the Help Desk group will not be able to change any users passwords regardless of when I add them. This still seems really strange.... so now I need to keep track of what ACE I've applied to what group, and reapply the ACE using the ACE Wizzard each time I make a user part of an existing group. This is totally crazy!!!


    Yes, documentation is extremely important. It's time consuming, pain, but necessary. Welcome to the world of Active Directory. Pretty soon, you might even start think of ways in which to automate such tasks using scripts and visit the microsoft scripting center.
    -----------------------------
    Can someone show me where I'm going wrong? Thanks in advance. .

    So here's Microsoft's Technet article on delegating authority:http://technet.microsoft.com/en-us/magazine/2007.02.activedirectory.aspx

    This should give you a good example of what your doing and how it all works.

    Best place to learn is Microsoft Technet. Lots to read but Welcome to Microsoft Active Directory.... where Reading is everything.

    +
    0 Votes
    Jasonjb1222

    " If I add Dan Holme to the Help Desk group, he can reset passwords, if I log off as the administrator, and login as Barbara, log out as Barbara, log in as Admin, log out as Admin, and log in as Dan (ya... that was stupid, but I doesn't work unless I log out and in a bunch of times.... 3 seems to be the magic number; after that the "reset password" ace appears in the ACL for Dan and ..."

    * * * * * *
    Anyhow, likely your magic number is 3, because the system or domain policies specify that the system should keep cached credentials of users on a system numbering 3.
    This makes it easier and faster for someone to log into a system, if for example a domain server cannot be contacted using cached credentials.

  • +
    1 Votes
    seanferd

    but I've always been under the impression that policies applied to Groups and Users, not OUs. So, following this possibly completely wrong understanding, you would have a Help Desk Group which is allowed the pwd rst permissions, and adding Dan to this group would give him these permissions as well (allowing that you did not specify that Dan as a User does not have this permission).

    +
    2 Votes
    Curt

    I think you're right about the ACE being applied to the Group and not to the OU. Not sure why I called the Help Desk group an OU in my previous question, because it's not an OU, and that's not my intention. With that out of the way, what you say would make sense, except, when I add Dan to the Help Desk group, Dan can't reset passwords.

    ---------------------

    Just went back and re-read and now I know why I used "OU" terminology instead of the "Group" term. The ACE is applied to the OU, not the group. Also, I think I've answered my question that I started out with. If I add Dan Holme to the Help Desk group, he can reset passwords, if I log off as the administrator, and login as Barbara, log out as Barbara, log in as Admin, log out as Admin, and log in as Dan (ya... that was stupid, but I doesn't work unless I log out and in a bunch of times.... 3 seems to be the magic number; after that the "reset password" ace appears in the ACL for Dan and he can reset passwords; before the multi login/logout, the ACE does not appear in the ACL and Dan can't reset passwords @#$^%^#/????

    ---------------

    Noticed that inheritance was turned off for all my users. Not sure how as new users have inheritance on by default. After turning inheritance back on for all users and doing the login/logout dance a few times, everything is working and people that I add to the "Help Desk" group are instantly showing the ACE in effective permissions.

    +
    0 Votes
    seanferd

    OK then, I'm out. See the replies from professionals with experience below. Good luck!

    +
    2 Votes
    OriginalM

    If you add a user to a group with the proper rights the user is needing to do something on a file share or in AD. The user itself must do a logoff - logon to get the rights assigned to its account.

    If you have multiple DC's it could take up to xx minutes - depending on server replication - before the rights are replicated to its account on its logon server.

    +
    2 Votes
    CG IT

    you said:

    I've made it to the end of Chapter 2, and I think I understand what's going on, but it still doesn't seem reasonable.

    What is reasonable to you isn't necessarily reasonable to Microsoft. you really have to look at it in a security context rather than what is easiest to do or what would be reasonable to you.

    When I started, I thought I was giving users in the "Help Desk" group the permission to reset other users passwords (which is apparently wrong). Now, it appears to me that I was actually giving users the privilege of having their password changed by someone currently in the Help Desk group. So if I add a new user, I can automatically know that existing Help Desk group members will be able to change the new users password, but if I add somone to the the Help Desk group, that new member of the Help Desk group will not be able to change any users passwords regardless of when I add them. This still seems really strange.... so now I need to keep track of what ACE I've applied to what group, and reapply the ACE using the ACE Wizzard each time I make a user part of an existing group. This is totally crazy!!!


    Yes, documentation is extremely important. It's time consuming, pain, but necessary. Welcome to the world of Active Directory. Pretty soon, you might even start think of ways in which to automate such tasks using scripts and visit the microsoft scripting center.
    -----------------------------
    Can someone show me where I'm going wrong? Thanks in advance. .

    So here's Microsoft's Technet article on delegating authority:http://technet.microsoft.com/en-us/magazine/2007.02.activedirectory.aspx

    This should give you a good example of what your doing and how it all works.

    Best place to learn is Microsoft Technet. Lots to read but Welcome to Microsoft Active Directory.... where Reading is everything.

    +
    0 Votes
    Jasonjb1222

    " If I add Dan Holme to the Help Desk group, he can reset passwords, if I log off as the administrator, and login as Barbara, log out as Barbara, log in as Admin, log out as Admin, and log in as Dan (ya... that was stupid, but I doesn't work unless I log out and in a bunch of times.... 3 seems to be the magic number; after that the "reset password" ace appears in the ACL for Dan and ..."

    * * * * * *
    Anyhow, likely your magic number is 3, because the system or domain policies specify that the system should keep cached credentials of users on a system numbering 3.
    This makes it easier and faster for someone to log into a system, if for example a domain server cannot be contacted using cached credentials.