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.
Use Group Policy to define accounts or services that are allowed 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.
Use Group Policy to define accounts or services that are not allowed to log on locally
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.
Use Group Policy to allow access to computers from 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.
Use Group Policy to allow or deny access to Remote Desktop Services
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.
Group Policy order can be confusing. To understand how exactly Windows applies one GPO (Group Policy Object) versus another, you can use the “LSD OU” rule.
You should always ask yourself two questions when dealing with Group Policy:
Where are you (local, site, domain, or organizational unit)?
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.
msadministrator 