As an IT administrator, one of the most common tasks you are involved in is administering security groups in Active Directory. As with all things, keeping your security groups simple is always best but sometimes (especially in larger environments) it is important to use groups of differing scopes or ‘visibility’ to allow or disallow certain groups or objects to become members, etc.
A security group’s scope determines to what extent a group can be applied in the domain or forest. Sometimes remembering all the details of each scope can be difficult so here’s a great table which summarizes each scope in terms of which security objects can be listed as members, where the group can be assigned permissions and what other scopes the group can be converted to.
||Group can include as members…
||Group can be assigned permissions in…
||Group scope can be converted to…
- Accounts from any domain within the forest in which this Universal Group resides
- Global groups from any domain within the forest in which this Universal Group resides
- Universal groups from any domain within the forest in which this Universal Group resides
|Any domain or forest
- Domain local
- Global (as long as no other universal groups exist as members)
- Accounts from the same domain as the parent global group
- Global groups from the same domain as the parent global group
|Member permissions can be assigned in any domain
||Universal (as long as it is not a member of any other global groups)
- Accounts from any domain
- Global groups from any domain
- Universal groups from any domain
- Domain local groups but only from the same domain as the parent domain local group
|Member permissions can be assigned only within the same domain as the parent domain local group
||Universal (as long as no other domain local groups exist as members)
I wanted a quick script to determine the current logged on user’s SID which I could then write into a new script for example to log each user’s SID at logon (during a logon script, etc).
The script I wrote below uses the environment variables USERNAME and USERDOMAIN to determine who the current logged on user is, and which domain they have logged on to. That information is then used to in a call to the getSid() function which connects to the local computer WMI service and queries it to retrieve the SID for the current user from the Win32_UserAccount wmi class.
First we want to find the current user and domain that they have logged on to:
'find current user & domain
Set wshShell = CreateObject("WScript.Shell")
strUsername = wshShell.ExpandEnvironmentStrings("%USERNAME%")
strDomain = wshShell.ExpandEnvironmentStrings("%USERDOMAIN%")
We’ll then show that information to confirm we’ve retrieved the right information:
WScript.Echo "Username: " & strUsername
WScript.Echo "Domain: " & strDomain
'use the user/domain information to retrieve the SID of the user and print it to the screen
The code above makes a call to a function called ‘getSid() so lets write that procedure. The procedure below creates an object with reference to the local machine’s WMI service, and then retrieves the SID information from the Win32_UserAccount class. It would be better programming practice to pass the username and domain variables to the function and use those parameters locally in the function, but this was written quickly to illustrate the idea.
Private Function getSid()
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set objAccount = objWMIService.Get("Win32_UserAccount.Name='" & strUsername & "',Domain='" & strDomain & "'")
getSID = objAccount.SID
That’s it. This will return the SID for the currently logged on user. Hope this helps.
Are you an IT administrator and want to make sure your users are authenticating against a local domain controller? Do you want to make sure they’re running their logon scripts locally and not from a server 20,000 kilometres away?
To check and make sure, its easy. Just open a command prompt on a computer on your domain and type:
This will print the value of the environment variable LOGONSERVER giving you the machine name of the domain controller used.
Its widely known knowledge, but sometimes you just never know. I hope this helps somebody out.