Your network contains an Active Directory forest named contoso.com. The forest functional
level is Windows Server 2012 R2. The forest contains a single domain.
You create a Password Settings object (PSO) named PSO1.
You need to delegate the rights to apply PSO1 to the Active Directory objects in an
organizational unit named OU1.
What should you do?
A.
From Active Directory Users and Computers, run the Delegation of Control Wizard.
B.
From Active Directory Administrative Center, modify the security settings of PSO1.
C.
From Group Policy Management, create a Group Policy object (GPO) and link the GPO to
OU1.
D.
From Active Directory Administrative Center, modify the security settings of OU1.
Explanation:
PSOs cannot be applied to organizational units (OUs) directly. If your users are organized
into OUs, consider creating global security groups that contain the users from these OUs
and then applying the newly defined finegrained password and account lockout policies to
them. If you move a user from one OU to another, you must update user memberships in the
corresponding global security groups.
Go ahead and hit “OK” and then close out of all open windows. Now that you have created a
password policy, we need to apply it to a user/group. In order to do so, you must have “write”
permissions on the PSO object. We’re doing this in a lab, so I’m Domain Admin. Write
permissions are not a problem
1. Open Active Directory Users and Computers (Start, point to Administrative Tools, and
then click Active Directory Users and Computers).
2. On the View menu, ensure that Advanced Features is checked.
3. In the console tree, expand Active Directory Users and
Computers\yourdomain\System\Password Settings Container
4. In the details pane, right-click the PSO, and then click Properties.
5. Click the Attribute Editor tab.
6. Select the msDS-PsoAppliesTo attribute, and then click Edit.
Not too sure on this one, I believe it is A
0
1
Yep, it’s B.
http://technet.microsoft.com/en-us/library/cc732524.aspx
You right click on the OU and the choose delegate control.
1
0
It’s B indeed. You go to ADAC and properties of PSO and change the permissions. You don’t use Delegate control.
1
0
Yes you’re right. It’s definately B
1
0
But you CAN use Delegate Control, and the object classes in question are exposed there.
0
0
As you described below yes you can, however take much longer than simply changing the permissions of the PSO object.
0
0
My hangup is this-
When you’re editing the security of the PSO, you’re saying who can apply and edit it, but it’s not confined to any single OU. Based off my understanding, you’re allowing USERX to apply this PSO to anyone in any OU.
However, by using the delegation of control on the OU, you’re saying USERX can apply a PSO to objects in that OU and that OU only.
Again, based off my understanding, I would see this as best done through ADUC with the delegation wizard to confine it to the right OU.
0
0
Tested on my 2012R2 lab:
Going to AD AC,select Tree View, domain\System\Password Settings Container.
On the right, select the PSO1, right click, Properties, under “Extensions”, you have another window that shows : Security and Attribute Editor tabs
Under Security tab, you select the desired users, has to have the following rights :
(all under “ms-DS-*” related to the attributes in question).
What is said in the “Explanation”, is to wich Global Security Group to apply the said PSO.
At the same time, if one goes to Active Directory Uses and Computers, and selects the Delegaton of Control Wizard, and selects Create a custom task to delegate, then we can select:
msDS-PasswordSettings objects and msDS-PasswordSettingsContainer objects
and then we can select the permissions to Read and Write the said ms-DS* objects.
That being said, as it apparently can be done throught AD Administrative Center,or AD Users and Computers, I think this is a very badly worded/proposed question.
A and B seem possible and correct
0
0
Furthermore, the Delegation of control wizard, at the end of its run says :
name_of_the_user
They have the following permissions
Full control
For the following object types:
msDS-PasswordSettings
msDS-PasswordSettingsContainer
and the following link : https://technet.microsoft.com/en-us/library/cc770394%28v=ws.10%29.aspx
says:
By default, only members of the Domain Admins group can create PSOs. Only members of this group have the Create Child and Delete Child permissions on the Password Settings Container object. In addition, only members of the Domain Admins group have Write Property permissions on the PSO by default. Therefore, only members of the Domain Admins group can apply a PSO to a group or user. You can delegate this permission to other groups or users.
You do not need permissions on the user or group object to be able to apply a PSO to it. Having Write permissions on the user or group object does not give you the ability to link a PSO to the user or group. The owner of a group does not have permissions to link a PSO to the group because the forward link is on the PSO. The power of linking a PSO to the group or user is given to the owner of the PSO.
1
0
The strangest thing is you need to delegate the right to apply PSO to objects in an OU. In all documentation about PSO there’s a statement that you don’t need rights on users or groups to assign a PSO.
0
0
yes B is the answer
0
0
Unbelievably individual friendly website. Immense info available on few gos to
nba 2k16 vc coins http://blog.dnevnik.hr/phylliscora/2016/05/1632020413/nba-2k16-guide-for-novices.html
0
1
Not so sure about this one….
0
0
Saad says:
August 9, 2015 at 8:46 am
yes B is the answer
Saad says:
August 9, 2016 at 5:55 pm
Not so sure about this one…
You’re a useless sack of shit. I’ve seen your replies on this site and they’re all the same. If you think XYZ is the answer, provide some explanations to it, otherwise you’re just quoting the provided answers and that’s not helpful. Stop spamming the site with your useless shit. And if you’re not sure about the answer, then all the more reason to STFU. Lastly, stop spamming useless replies to the same question, TWICE in a day. I’ve seen other people call out on your useless comment and I completely agree with them.
1
0
PSOs cannot be applied to organizational units (OUs) directly. If your users are organized into OUs, consider creating global security groups that contain the users
from these OUs and then applying the newly defined fine-grained password and account lockout policies to them.
To apply a PSO to an user or group, you must have write permissions on the PSO object. So the answer is B for sure.
0
0