|
Home > Archive > 70-217 > January 2003 > who can explain this?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
who can explain this?
|
|
| me? I dunno... 2003-01-15, 9:55 pm |
| You are the enterprise administrator of a windows 2000 domain tree that has five domains. All domains are in native mode. Each domain has one or more users who are help desk staff. Each domain has a global group named Help Desk members that contains the help desk staff from each domain. There is an OU named Interns in the root domain. You want all help desk staff to be able to reset passwords of the users in the Inters OU. What should you do?
C) Create a new universal security group named Help Desk Staff in the root domain. Place the five Help Desk members groups in the Help Desk Staff group. Create a new local security group named reset Interns in the root domain. Place the Help Desk Staff group in the Reset Interns group. On the Interns OU, assign the reset password permission to the Reset Interns group.
D) Create a new universal security group named Help Desk Staff in the root domain. Place the five Help Desk Members groups in the Help Desk Staff group. Create a new local security group named reset Interns in the root domain. Place all users from the Interns OU in the Reset Interns group. On the reset Interns group, assign the Reset Password permission to the Help Desk staff group.
C is shown as the right answer but there is no explanation as to why, and I dont know what it is, any help would be appreciated | |
| jeff_j_black 2003-01-16, 12:20 pm |
| You are granting permission to all of the members of the various Helpdesk groups to be able to reset passwords of Interns, which happen to be in the root domain. Basic Microsoft permission design:
Users who you are assigning access to get placed in Global Groups.
Global groups get placed in Local Groups in the domain where the resource resides.
Permissions (or delegated authority to the OU) are granted to the selected Local Groups.
A Universal Group is used in this case, to assemble a membership of Global Groups from several domains. Then permissions are granted by placing this group into a local group that has the appropriate permissions configured on the OU, to be able to modify passwords.
You would not put the Interns into a Local Group, (Answer D) as delegation of authority is granted for OU containers, not security groups.
What seems to be a sticking point for you, is the difference between security groups and OU. OU are containers, that can be used to logically divide active directory users, computers, printer and shares. Typically OU are used to provide delegation of authority, (as is the case for this question), to hide directory objects, to apply group policy, etc.
Security groups are for granting access permissions to files, folders, printers, other resources, and for delegation of authority. (Giving members of a security group the permission to access directory objects such as OU.) | |
| me? I dunno... 2003-01-16, 6:45 pm |
| thanks Jeff, sorry for the delay, I have spent the day reviewing groups, permissions, and shares. I still dont understand the relationship between OU/gpo and security group boundaries. I cant believe I have read 2 textbooks on this and I still dont get it, I will review group policy again.
unless... any domain local group moved into an OU has gpo's applied automatically and those policies propagate to the global group because it is a member of the dl group, thus policies are applied to the global group in a round about way? | |
| me? I dunno... 2003-01-17, 2:36 am |
| 'The policies in a GPO apply only to users who have read permission for that GPO. You can filter the scope of a GPO by creating security groups and then assigning Read permission to the selected groups. Thus, you can prevent a policy from applying to a specific group by denying that group Read permissin to the GPO.'
So this would only apply to local, domain local, or universal groups? | |
| me? I dunno... 2003-01-17, 3:36 am |
| I am now happily engaged in the rookie process of locking down everything in sight. what needs to be figured has been figured, thanks again. | |
| jeff_j_black 2003-01-17, 8:25 am |
| Again, from our other thread, you don't apply GPO to security groups. You can use security groups to filter GPO, as in your example above, denying read permission to the GPO for a particular group would prevent the GPO from affecting that group.
But if you are designing OU, you are going to populate those OU with Active Directory User Objects, not security groups.
Security groups are for granting permissions to files, folders, printers, shares and even read access to a GPO. But beyond that and the fact that you see security groups in AD Users and Computers plug-in, Security groups have no relationship to OU.
Example: you install Windows 2000 Server on a computer as a stand-alone server that is not a member of any domain. No Active Directory, no OU, only local Group Policy. That policy can be applied to the machine itself and the users that have accounts on that machine. Yes, you have all kinds of Local and Global Security Groups on this stand-alone box, but there's no relationship to Active Directory.
In installing Active Directory, by running DCPROMO, you initialize a database that can do incredible things. But for kicks, try granting NTFS permissions to an OU. You can't, because OU are a different type of object than Security Groups. Just as you can't apply GPO to a Security Group. | |
| me? I dunno... 2003-01-19, 4:03 pm |
| Question 16: In your company, you have a group of people who are working on a special high-security project. Because these user accounts have different requirements for passwords and account lockout than the rest of the organization, you create a new domain for them called projecty.companyxyz.com.
You have created a GPO called Lockdown which enforces strict restrictions on the desktop environment that a user receives. You have linked this GPO to the projecty.companyxyz.com domain.
However, you are concerned that this GPO will affect members of the Domain Admins group for this domain. You do not want these restrictions placed on the Domain Admins group. What is the easiest way to ensure that the Domain Admins does not receive setting from this GPO?
Correct Answer: B
Check the box to Deny the Apply Group Policy permission for the Domain Admins group.
Your Answer: B
Check the box to Deny the Apply Group Policy permission for the Domain Admins group.
--------------------------------------------------------------------------------
Explanation: By default, Domain Admins do not have the Apply Group Policy permission. However, Domain Admins are also Authenticated Users and by default Authenticated Users have Read and Apply Group Policy permissions. Therefore Domain Admins will have all GPOs applied to them by default. There are two options to prevent this default behavior:
1. Remove Authenticated Users from the list on the security tab of the GPO, and add a new security group with the Apply Group Policy and Read attributes set to Allow. This new group should contain all the users that this Group Policy is intended to affect.
2. Set the Apply Group Policy attribute to Deny for the Domain Admins. This will prevent the GPO from being applied to members of that groups. Remember that an ACE set to Deny always takes precedence over Allow. Therefore, if a given user is a member of another group that is set to explicitly Allow the Apply Group Policy attribute for this GPO, it will still be denied.
Just when I thought I had it figured, this explanation screws things up again. It appears to be inferring an OU being applied on the basis of membership in a security group. How am I reading this wrong? | |
| jeff_j_black 2003-01-19, 5:18 pm |
| This what I mean when I say filter GPO by security group.
You applied the GPO to the Domain, so all AD User and Computer objects in the Domain would be subject to that GPO. (Not security groups.) To prevent the policy from applying to the administrators security group, you would change that security groups permissions, such that it would not have read or apply permissions.
Again, GPO apply to AD containers and AD objects in those containers.
Security groups are granted or denied permissions to read and or apply the GPO.
When you deny 'apply group policy' to a security group, for performance reasons it is best to also deny 'read' permissions as well.
AD objects (Like GPO) have ACL, (Access Control Lists) just like files and folders do. ACL control who (User accounts and Security Groups) has access and what type of access they have to that object. | |
| me? I dunno... 2003-01-19, 8:57 pm |
| thanks Jeff, btw, watched Barrett-Jackson this weekend while reviewing, thought I might see you there... | |
| jeff_j_black 2003-01-19, 9:04 pm |
| Damn, you have me at a loss on the Barrett-Jackson reference? | |
| me? I dunno... 2003-01-19, 9:21 pm |
| Barret-Jackson Auto Auction, rare collectibles, one of a kinds, and general neet stuff. |
|
|
|
|