The easiest way to create an ADMX template is to build an ADM template first and then convert the latter with the help of Microsoft’s free ADMX Migrator tool.
Administrative templates let us create custom Group Policy settings. Administrative template files have two different versions. Windows Vista introduced templates with the .ADMX extension. These templates use an XML syntax and can be a lot more difficult to decipher and create by hand. On the other hand, templates with the .ADM extension are straightforward and have a simple syntax that allows you to create new Group Policy templates quickly.
Group Policy is nothing but flexible and extremely powerful when it comes to both configuration management and installation of software. In addition, Group Policy is one of your best tools for securing your endpoints. You can manage anything and everything from Firewall rules, account privileges, application white-listing, etc. You can also manage user rights as well.
Computers and Users in your environment have a lot of rights, by default, that they don’t need. Using Group Policy, we can manage these privileges and start to lock-down our environments without making it burdensome for our end users. One such privilege is the ability to Log on Locally.
By default, anyone that has the correct username and password can log on locally to a system, but do you really need to log on to a server in your datacenter using a local account? Some of you might, in this case you should explicitly allow certain accounts to have this privilege. Instead of using the default setting of “if you have a local account you can log in to this system”, but instead restrict this at a global level. This ensures that your systems are properly managed and no one was being lazy or malicious by creating a one-time account they forgot about.
Let’s take the opposite approach. Do you have systems on your network(s) that should only be logged on by specific individuals, accounts, services, etc? Instead of relying on plainly on the security of your username and password, we should restrict this right to the specific accounts, computers, users, etc. that should have access. Only then, if they have the correct credentials are they allowed to login over the network.
By restricting this access to only the certain machines or users within a specific group, someone who has either found a set of credentials or has somehow infiltrated your network will only be able authorize a set of systems because others have been restricted.
Another example is to manage who has access to Log on Remote Desktop Services permissions. Does everyone need to access a set of systems (this goes for both workstations and servers)? I bet not, so why just enable RDP (Remote Desktop Protocol) for anyone who has valid credentials? We should tightly restrict who has access to our systems, especially when using RDP.
For all situations regarding user rights and access to systems, we should always restrict access as much as possible. The key is to create these restrictions without being burdensome for your end-users. There is a fine line, but we should always attempt to be reasonable with this approach. Some systems just shouldn’t be accessed over RDP or locally, this will be up to the discretion of your organizations risk. Providing clear guidance and allowing your management to either enable these restrictions or to accept the risk is all that we as IT professionals can do.
To run a PowerShell script on multiple computers via Group Policy, you can work with an Immediate Scheduled Task. The main advantage over logon scripts is that you can execute your script with admin rights.
Group Policy allows you to add and remove users to an Active Directory (AD) group. Using this feature improves security because you can ensure that high-risk security groups only contain the users that you specify via Group Policy.