Allow Admins to log on to W2K Desktop with Admin Rights
Novell Cool Solutions: Trench
By Ben Commins, David Kretschmer
Digg This -
Posted: 24 Sep 2003
We wanted to have our support and admin staff be able to log onto a W2K desktop with full local administrator rights. All other users needed to have a restricted desktop environment. Also we needed to be able to manage these permission groups via ConsoleOne.
We have a single NDS container for our users. Firstly, we wanted to have certain groups with different W2K policies. To our frustration, W2K server only allows policies to be applied to Organisational Units, not groups. This meant either we needed to split our NDS users into containers to mirror the appropriate AD structure required for applying different security policies, or find another way. We found another way.
1. Create an OU in NDS called NT-Groups
This is of course optional. You can use existing OUs, however having a separate container means that NT groups are not going to be confused with NDS groups, and there is very little to configure in the NAM sync process.
2. Configure NAM to synchronise the new groups container to the appropriate AD container. We chose not to sync it to our users container in AD (ou=NDSUsers*) but to the default Users container in AD (ou=Users). This is to keep the groups separate from 2000 users. Don't forget to:
- Ensure the new group container is the NAM search container
- Add it to the consensus
- Our configuration does not expand groups to include users
- Edit the asamwin.conf file e.g.
OU=Groups * W2K,OU=WH OU=Users, dc=xxx,dc=yyy etc
3. The result will be a NDS group appearing in W2K complete with users.
Local Workstation Rights
So how do you give these AD groups extra workstation privileges, such as local admin?
There is a great little util in the W2K resource kit called CUSRMGR.EXE that will copy an AD group into any local security group on a workstation.
As such, the groups created and administered in NDS, are synced to AD and then copied into the appropriate local security group on the workstation.
To use this utility:
- Open "Active Directory Computers and Users", and edit the properties of your top level domain container.
- Edit the Default Domain Policy, found in the Group Policy tab.
- Nav to Computer Configuration > Windows Settings > Scripts (Startup/Shutdown)
- Edit the startup script
- Add the following command:
Cusrmgr.exe *m \\%computername% - alg <Local_Group_Name> *u <AD_Group_Name>
NOTE: You may also want to deliver this via ZENworks for Desktops. We have not tested this, but will do in the future.
Since W2K does not allow you to apply policies to groups, you'll need to work around that too.
You can import the policy into ConsoleOne and distribute via ZEN, but this has proved to be a bit flakey, and impossible if you don't have ZfD4. Instead, extract all the policy settings you want and create registry files to come down via a login script, or you can use ZfDx to distribute the registry entries. This way, you can assign different arrangements of lockdowns to NDS groups (i.e. SupportTeam, LocalWSAdmin, etc).
The result will be the ability to create a library of policy settings that can be distributed to different NDS groups. The bonus is the new settings are distributed even if you login from the desktop!
Microsoft has published a document to explain the policies and their associated registry settings. I can*t find it at present, but with some logic, research, and windiff/Snappshot you'll be able to have a pretty good go at it!
After following these steps, you will be able to do the following:
- Use C1 to assign users local Power User rights
- Use C1 to assign users local admin rights
- Apply W2K policies to NDS groups, to be delivered via ZEN or the login script
If you have any questions you may contact David at email@example.com
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com