Quantcast
Channel: TechCenter
Viewing all articles
Browse latest Browse all 2350

AccessControlGroupNamingStandard.arsaddon

$
0
0
Revision 1 posted to Active Roles Wiki by Lee A on 2/27/2014 3:37:04 PM

An ARS script policy example to enforce a naming convention. I first experimented with using a RegEx but this became to complex for me to come up with, so whilst the first naming element is still set as a RegEx this is really so that an end user can click on the policy description to get the required help.

This solution requires that you have a pretty rigid naming standard that is fully defined. I have this for a specific group type that we use to manage access control so I wrote a script to check onPreCreate that the naming standard was correct. I could have done more in the script but wondered what sort of performance hit it would give if I started binding to objects in the directory to check the dependant groups existed and that the names matched but just decided that I'd just assume that the admins, when setting this up didn't make any typos in the name, i.e I don;'t check that a computer name exists for example.

Our access control system uses start up scripts which looks for groups in AD to determine who should have rights. Yes I know this can be done in a GPO but actually GPOs are not that flexible especially when it comes to user rights and besides this post is not to discuss the merits of that system but to show how a naming standard might be enforced using ARS.

I'm happy to start a discussion on anyones thoughts on how efficient the script might be and it it can be improved, maybe even made to be a little more generic. Now I'm writing this I can think of ways of allowing the group naming elements to be defined as parameters in the script but again this could get very complex.

Anyway so you can follow this and test of course I better explain briefly the naming standard it is enforcing:

<Platform/Collection><TargetType>-[<Target>][-<Target>]-<item>

The group name elements are delimited by the hypen. The first element is 3 characters in length and denotes the group type and also includes a scope element based on the machine type.

Chr 1 of the first element is either:

A (Access Control Collection - a group that contains computers to be managed)

W (workstations only)

S (Servers only)

I (Infrastructure Servers Only)

M (Machine - will target a specic manchine name that will be the 2nd element in the group name)

C (Collection - uses a group that starts with an A to target an Access Control Collection - see above)

the next 2 Chrs of the first element indicate what the group controls:

LG = Local Group

UR = User Right

CC = Collection used only with an ACC- group

The 2nd element will depend on the first, i.e. if the 1st element is ACC then the 2nd will be a collection name, e.g. ExchangeServers (not No Spaces)

if the first element is Mxx then the 2nd element will be a computer name.

The 2nd element can be used to denote a scope which can be 1 or 3 or 4 characters long.

1 chr is an environment, e.g. P = Production T = Test. The first letter of our server namign standard idicates the environment which is how the access control script decide ont eh scope of management and where the settings apply.

3 chr is a site, e.g. LON or NYC. Our server namign convention includes this as the 2,3 and 4th character in a server name so again this is used to compare the access control group name.

4 chr is both environment and site so PLON = Production in London

The last element is the LG (local group name) of the UR to be managed, e.g. Administrators or SeBatchLogonRight (for logon as a batch right)

That should help make sense of the scripts I've written and if you have a rigid naming standard then yo may be able to use the same strategy to enforce the namign standard in your environment.

Example group names to hopefully make this clear:

SLG-Administrators : Members have local admin rights on all Servers

SLG-P-Administrators : Members have local admin rights on all Production Servers

SLG-LON-Administrators : Members have local admin rights on all LON Servers

SLG-PLON-Administrators : Members have local admin rights on all LON Production Servers

ACC-RMADServers : Used to apply access control to 'RMAD Servers' collection

CUR-ExchangeServers-SeInteractiveLogonRight : Members can Logon Locally to the 'Exchange Servers' collection

CLC--PasswordManagerServers-Administrators : Members have local admin rights on the 'Password Manager Servers' collection

CLC--P-PasswordManagerServers-Administrators : Members have local admin rights on the Production 'Password Manager Servers' collection

CLC--LON-PasswordManagerServers-Administrators : Members have local admin rights on the LON 'Password Manager Servers' collection

CUR-ExchangeServers-P-SeInteractiveLogonRight : Members can Logon Locally to the Production 'Exchange Servers' collection

CUR-ExchangeServers-LON-SeInteractiveLogonRight : Members can Logon Locally to the LON 'Exchange Servers' collection

CUR-ExchangeServers-PLON-SeInteractiveLogonRight : Members can Logon Locally to the LON Production 'Exchange Servers' collection

(Please visit the site to view this file)


Viewing all articles
Browse latest Browse all 2350

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>