User cannot admin own user account

[guest]

Subject:
--------------
User cannot admin own user account

Cause:
--------------

A user account has been delegated control of user accounts within a
particular OU that just happens to include his own user account.

The user can now add secondary email addresses to any of the user account
within the OU, apart from his own. When he tries he sees an Access Denied
LDAP error. If the Security tab on his user account Properties is checked
the 'Allow permissions to propagate from parent...' checkbox is not
selected.
If it is selected, secondary email addresses can be added, but within a
short time if the setting is checked again it has been deselected again.

Analysis & Finding:
--------------
1. Windows AD introduces object AdminSDHolder, which is used to control the
permissions of user accounts that are members of protect groups.
http://support.microsoft.com/?id=232199
Description and Update of the Active Directory AdminSDHolder Object

2. If the ACL is different, the ACL on the user object is overwritten to
reflect the security settings of the AdminSDHolder object (which includes
disabling ACL inheritance).

3. This protects these administrative accounts from being modified by
unauthorized users if the accounts are moved to a container or
organizational unit in which a user has been delegated administrative
privilege for the modification of user accounts.

4. Every hour, the Windows 2000 domain controller that holds the primary
domain controller (PDC) Flexible Single Master Operation (FSMO) role
compares the ACL on all security principals (users, groups, and machine
accounts) present for its domain in Active Directory and that are in
administrative groups against the ACL on AdminSDHolder object.
As you found, some time later, the inheritance check will be remove
automatically.

5. If the user is direct or transitive member of those protected group, it
will not inherit permission from parent container. That is why PDC remove
the inheritance check during every hour checking.

6. With this finding, I easily reproduce the symptom in my test environment.

7. As the article http://support.microsoft.com/?id=817433 mentioned, all
groups below are protected groups on Windows 2000 SP4 DC.
The following list describes the protected groups in Windows 2000:
• Enterprise Admins
• Schema Admins
• Domain Admins
• Administrators

The following list describes the protected groups in Windows Server 2003 and
in Windows 2000 after you apply the 327825 hotfix or you install Windows
2000 Service Pack 4:
• Administrators
• Account Operators
• Server Operators
• Print Operators
• Backup Operators
• Domain Admins
• Schema Admins
• Enterprise Admins
• Cert Publishers
Additionally the following users are also considered protected:
• Administrator
• Krbtgt

8. In one word, the symptom is expected which is designed to protect those
important account, member of protected group from being modified by
unauthorized user

Suggestion:
--------------

If the symptom is acceptable, please feel free to let me know if you have
any further questions.

If the symptom isn’t acceptable, please feel free to follow the method
below to resolve. [It isn’t recommended]
You can enable inheritance on the adminSDHolder container by using Active
Directory Users and Computers.
The path of the adminSDHolder container is
CN=AdminSDHolder,CN=System,DC=<MyDomain>,DC=<Com>
Note: If you use Active Directory Users and Computers, make sure that
Advanced Features is selected on the View menu.

To enable inheritance on the adminSDHolder container:
1. Right-click the container, and then click Properties.
2. Click the Security tab.
3. Click Advanced.
4. Click to select the Allow Inheritable permissions to propagate to
this object and all child objects check box .
5. Click OK, and then click Close.
The next time the SDProp thread runs, the inheritance flag is set on all
members of protected groups. This procedure may take up to 60 minutes. Allow
sufficient time for this change to replicate from the primary domain
controller (PDC).

[guest]

Subject:
--------------
clone the local group policy settings to other machines

Cause:
--------------
Customer wonder if he can clone the local group policy settings to other
machines

Resolution:
--------------

1. Log on the client with admin account
2. Copy the script file to your local location. Here we use for
d:\script.vbs
3. Create a txt file and type the words following:
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="Local Group Policy"
"GPOName"="Local Group Policy"

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Shutdown\0\0]
"Script"="D:\\ script.vbs " (the script file location)
"Parameters"=""
"ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\Scripts\Startup]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts\Shutdown]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts\Shutdown\0]
"GPO-ID"="LocalGPO"
"SOM-ID"="Local"
"FileSysPath"="C:\\WINDOWS\\System32\\GroupPolicy\\Machine"
"DisplayName"="Local Group Policy"
"GPOName"="Local Group Policy"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts\Shutdown\0\0]
"Script"="D:\\ script.vbs " (the script file location)
"Parameters"=""
"ExecTime"=hex(b):00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group
Policy\State\Machine\Scripts\Startup]
4. Rename the file as registry.reg and double click this file
5. Reboot the client and the shutdown script woks
Note: I have also tried to use the UNC path to locate the script file in
network, which does not work, so I have to copy the script file locally