| Author |
 Topic  |
|
|
aval
Honorable But Hopeless Addict
USA
3273 Posts
Status: offline |
 Posted - 07/19/2012 : 11:08:37 PM
|
- W2K3 SP2 domain controller (only one - so no replication)
- Windows 7 SP1
Test environment.
If I add Mike.Williams to the Account Operators group, should that not be reflected in the whoami /groups command?
He is logging on the the W7 SP1 client. Logon succeeds.
I've logged on and logged off a dozen times and I've even restarted the client machine.
Tried a different user in different OU then a brand new user (just created). I can add them to group XYZ but when logging on the the client, they are not shown as members of the group in question.
Cannot try another client machine: there is none.
Problem was discovered when delegating the right to create new mail contacts (in Exchange 2007 - EMC - RSAT in fact) to these users. When they attempt to create a mail contact: Access is denied (gibberish) The user has insufficient acces rights.
Want to post dsquery output and the client output and compare - but will have to wait until tomorrow.
Anyone seem anything like this?
|
|
|
Playwell
Honorable But Hopeless Addict
Netherlands
4819 Posts
Status: offline |
Posted - 07/20/2012 : 03:58:09 AM
|
| Maybe it's an uac thing? |
'People who think they know everything are a great annoyance to those of us who do. '
Quote by Isaac Asimov
|
 |
|
|
wkasdo
Administrator
Netherlands
7403 Posts
Status: offline |
Posted - 07/20/2012 : 08:31:10 AM
|
It's a built-in local group in AD. This means it's never going to show up if you log on to a member server or workstation.
> the right to create new mail contacts
Don't use Account Operators. It's a legacy from NT4 that is far too powerful. Use the AD delegation wizard instead. |
Make it as simple as you can, but not simpler -- Albert Einstein |
|
|
|
aval
Honorable But Hopeless Addict
USA
3273 Posts
Status: offline |
Posted - 07/20/2012 : 2:49:46 PM
|
OK. That makes sense then (not appearing in whoami /groups).
And yes, "Account Operators" is indeed too powerful.
I was examining different ways to delgate control over certain Exchange operations, looking first at pre-RBAC options (what you would have with Exchange 2007) and then the much more granular Exchange 2010 RBAC options.
It appears that even if you make a standard user member of the Exchange "Recipients Administrators" security group, that is not enough for the user to create new mail contacts (for example) because they need right to create objects in Active Directory.
That's when I made the user member of the "Account Operators" security group.
Despite the power they are supposed to have, the user, even when member of the AO group, could not create a mail contact.
So it looks like, for some reason, even membership in that group does not enable object creation (???).
Maybe I can post a screenshot of the error tonight.
Otherwise, I'll try delegating appropriate rights to the "Contacts" OU in Active Directory (which would be the preferable "pre-RBAC" option).
|
Edited by - aval on 07/20/2012 2:52:08 PM |
|
|
|
aval
Honorable But Hopeless Addict
USA
3273 Posts
Status: offline |
Posted - 07/22/2012 : 5:51:56 PM
|
I think I might have discovered the problem.
OK. Account Operators is NT legacy and there's no point in using them anymore. But why didn't membership in that group allow creation of contact objects?
Looking at the description of the group "Members can administer domain user and group accounts", I see that it mentions nothing about contacts.
When I first delegated rights to my delegate, I quickly went through the wizard, too quickly, and granted rights on users (close enough, right?).
Well no. That did not work and I installed RSAT to see if the delegate could create a simple contact object in AD. The only option (Right click | New) was "User". So I removed permissions for the delegate and run the wizard once more, this time selecting "custom" and then "contacts".
Now the delegate can create contacts in the Exchange 2007 EMC just fine. |
|
|
| |
Topic |
|
Group membership does not take effect on client
