-
NetBIOS name should match your forest FQDN. So if
FQDN=adlunches.net
, NetBIOS name isADLUNCHES
-
Every AD forest has a server which indexes all the objects in the forest. This is known as the Global Catalog server.
- Each domain needs at least 1 GC server, can have more for redundancy. This is so it can find objects in other domains.
- Any DC can be GC.
- By default all DCs will be GCs. GCs take up disk space and bandwidth, but both are plentiful.
- Microsoft Exchange requires GC server to run.
- Allow logins via UPN eg. [email protected], which may be on same domain.
- GC servers should be deployed at sites with poor WAN links or filtered connections.
- GC facilitate login for members of universal groups, which are groups with members belonging to different domains.
- Sited near high use applications like Exchange.
-
Everything in the AD forest shares the same database schema and the structure of stored objects. Each domain has its own DB but the schema determines the design of that DB.
-
Trust relationships are generated automatically within the same forest between domains. Trust relations allow users in separate domains to connect to resources.
-
NTDS = NT Dir Services (old Win NT name). Database stored in NTDS.dit file, which stores data in X.500 standard.
-
Five operation master roles. To check roles, type
dcdiag /test:knowsofroleholders /v
for LDAP format or ornetdom query fsmo
this for FQDN format- Schema master: Make changes to schema. Forest-wide.
- Domain naming master: Add/remove/rename domains. Forest-wide
- RID master: Allocates RID pools, RIDs are appended to SIDs. Domain-wide.
- Can be placed on slow network link if AD objects are not created frequently.
- Placed on same DC as PDC emulator because PDC uses a lot more RID's than others.
- PDC emulator. Domain wide. Placed on network with most users to facilitate password changes.
- Time sync server. All DCs time sync with PDC, and clients sync with their DC.
- Final authority on domain passwords.
- Group policy editor makes changes here and replicates to other DCs.
- Infrastructure master: Keeps object references across domains in forest. Tracks object moves, renames, deletions across domains. Domain wide.
- In multi-domain forests, make sure IM role is not a GC server because otherwise it would not update the DCs of changes once it checks itself (GC) that object changes are already made. Fixed in Server 2008.
- Doesn't matter if there's only 1 forest and domain used.
-
Upon first domain logon, Windows creates Access token with these characteristics:
- To check last logon of user, go toADSI Edit -> Users -> Properties -> Last logon
- Delegation in Win Server 2003 allows admin to provide client PCs with creds to access selected services such as file servers to DL things. Go to ADUC, OU=Computers, Properties -> Delegation tab. Select delegation by service only to limit delegating authority.
- Service Principal Name in Svr 2008 allows for application-based accounts needed to access external resources. It's a CNAME for a AD record. Server 2008 and later manages the SPN accounts such that the sysadmin would not need to track password expiration/renewal upon which the application access will fail. Reference
- UserPassword attribute supported on iNetOrgPerson object, allows for importing into AD from non-AD LDAP server.
- Able to set one set of password policy to different OU in same domain.
- Can raise forest functional level to X only if all the domains inside are at least X and above.
- Forest trust allows sharing of information between separate forests.
- Dynamic entries in AD can be set to be automatically delete after a set amount of time has passed
- Convert between inetOrgPerson object and AD user object to faciliate inter-operability between AD non-AD directory services like LDAP. Reference
- AD recycle bin introduced Server 2008. Previously had to boot DC into recovery mode and do authority restore
- Can migrate child domain into root domain as an OU.
Reasons for:
- Keep different management structures separate
- Different budget requirement
- Different security level of each network; segregate access/write permissions.
Reasons not to:
- Adds complexity to administer.
- AD can now scale easily to manage millions of objects.
- Support multiple password policies per domain.
- Trusts create a path for user to access resources across domains, doesn't grant them permissions.
- If domain A trusts domain B, and user John in B, John has a path to access resources in A, but doesn't have permissions unless explicitly granted.
- Transitive trusts - A trusts B, B trusts C => A trusts C
- Shortcut trusts - Trust link created directly between two domains without going through others
- Forest trusts - Not automatically created, must be manually created by admin. Forest trusts are transitive.
- Realm trust
- Both system uses Kerberos
- Between AD and non-AD system.
- May be transitive or not, one or 2-way.
- External trust
- Used when a path is to a domain located in another forest not joined via forest trust. Ref
- Non-transitive by nature.
- Typically used to connect to NT4 (legacy) systems
You can check forest root domain by running this VBS code, gives result in LDAP format.
Set objRootDSE = GetObject("LDAP://RootDSE")
Wscript.Echo "Root Domain: " & objRootDSE.Get("RootDomainNamingContext")
- AD sites are used group together subnets which share same physical location.
- Site is a group of "well-connected networks". It allows you to model AD around your physical network.
- Site segregation can be due to security such as firewall instead of physical location.
- Managed under AD sites and services.
Note: Administered under AD sites and services
Sites in Active Directory® represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects in the directory, to build the most efficient replication topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent the logical structure of your organization.
- Occurs 15s after changes made on a site DC.
- All intra-site DCs are connected to each other via a ring connection (ie. each DC connects to 2 others) for <8 DCs.
- For >8 DCs, additional connections are made between the site DCs to ensure <4 hops for each DC to the others.
- Site links connect different sites, and created only manually by admin.
- Each site has a designated bridgehead server.
- Bridgehead DCs are responsible to replicate AD changes intersite when AD changes reach them.
- Preferred bridgehead DCs can be selected but if they go down, no replication will occur until the DCs come back online.
- Can have multiple bridgehead servers in 1 site, but only 1 is used.
- Site link configurables
- Schedule or frequency of inter-site replication.2
- Cost of site link (similar to routing metric)
- RPC over IP (or just IP) - Supports replication of all objects. Synchronous by nature. a. Intra-site uses IP only.
- SMTP - Supports all except file replication (ie. SYSVOL share containing login scripts and group policies). Asynchronous by nature.
- Automatically creates links between sites without configuration.
- Reconfigures when links go down.
- Selects bridgehead DCs with info from AD database.
- Always comes up with same results (links, bridgeheads) between sites.
- Troubleshooting tip: If connections not made between DCs, check for replication errors in event viewer and DNS related errors (of other DCs).
- To force KCC to rerun on a DC, go to
AD sites and services -> Site-name -> Servers -> [DC-name] -> NTDS Settings
. Then right clickAll tasks -> Check Replication Topology
repadmin /kcc site:NewYork
- Forces KCC to run on all DCs on New York site. Omit site argument to run KCC on local DC only.repadmin /SyncAll
- Force replicationrepadmin /BridgeHeads
- Show all DCs working as bridgeheads.
- If site A links to B and B links to C, then a site link bridge can be created from A to C.
- Created automatically by KCC, manual ones will be ignored unless automatic site bridging disabled.
- All accounts have SID associated, independent of user name, computer or group name.
- Check
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
for list of users that exist on local computer - Short SIDs are local profiles, longer ones are domain SIDs.
- Make sure
C:\Users\<username>
andProfileImagePath
reg key matches when renaming profiles so Windows recognises them if not Windows will create new profile - User name standards
- NT4 : Domain\Username. Limited to 20 chars.
- After 2000 (User Principal Name): [email protected] -> New UPN suffix can be created under
AD domains and trust
- When user is authenticated, access token is generated for that user.
- Access token can be used to access network resources. It contains SID.
- When user tries to access resources such as file server,
- SID in token is compared against the file server's access list to see if it has access.
- Group SID in token is compared to see if user belongs to group which has access.
- Once token generated, the SIDs on it allow it access even when user/group is denied permission. This persists until token is regenerated on re-logon.
- Login with UPN suffix need access to global catalog server.
- Account
- Set logon hours, restrict logon computers, unlock account (applies to new connections, not existing sessions)
- Account options -
- Disable account instead of deleting when user leaves (security certificates deleted as well).
- Disable delegation even when Windows allows it.
- Option to downgrade to DES encryption or enable AES 128/256 encryption.
- Disable requirement for Kerberos authentication removes timestamp (allows replay attack).
- Account expires on specified date.
- Profile
- Specify profile path to use roaming (network-hosted) profiles instead of local ones. Use %username%.
- Run script on logon.
- Specify location for user to store files (can map drive to specified location)
- Member of - Set groups user belongs to
- Remote Desktop Services Profile - Similar to Profile tab but for RDP only. Overrides Profile tab settings. Can disable RDP for specific user.
- Dial-in - Ignore for modern systems. Just make sure "Control access through NPS network policy" is set.
- Environment - Overrides client specified logon programs
- Sessions - RDP-only settings (note: can configure on server end as well)
- End disconnected session - Disconnect/end session after network disconnection after X mins
- Active session limit - Specify how long user can be connected.
- Idle session limit - Disconnect/end session after idling for X min.
- Allow reconnection - Specify reconnection allowed from any client or just originating session client.
- Remote control - Allow admins to observe/interact with user sessions.
- Copy profile as template for new user.
- Select multiple users -> Properties, allow you to change profile path for multiple users, logon scripts.
- Disable user account if needed.
- All domain computers need AD computer account.
- Password protected, randomly generated, automatically changed every 30 days w/o admin intervention. Password management is hidden from admins.
- Move computers to designated OU so group policies can be applied.
- If the computer account password the local computer differs from DC's, authentication fails and message
The trust relationship between this workstation and the primary domain failed
To fix, login with local admin account, move computer back to workgroup, then join back to domain to restore trust relationship.
-
Security vs distribution groups. Can switch any time. Note that if security change to distribution permissions not valid anymore.
- Distribution - No SID, security settings possible.
- Security - SID, can be assigned for object security.
-
Use nested groups to control shares. Also known as role-based access control.
- Eg. put Accounts in Invoice_share (R/W) group, to give them R/W, move them to Invoice_read (R) to remove group permissions.
- Abstracts away servers/shares hosting shared files; just moving groups.
- Used by enterprises with large number of people. Wikipedia on role-based access control
-
AD group types - Note can change types any time.
- Local
- Scope: local PC only
- Allowed memberships: Users, computers. Groups: DL, G, U
- Domain local
- Scope: Domain-wide
- Allowed memberships: Users, computers. Groups: DL, G, U
- Global
- Scope: Forest
- Allowed memberships: User, computers. Groups: G
- Notes: Can't be used outside domain.
- Universal
- Scope: Forest
- Allowed memberships: User, computers. Groups: G, U.
- Local
-
Example of how to apply group memberships.
-
Think of Global group as "Account groups" and Domain local groups as "Resource Groups". User accounts go into global groups which then get assigned to DLG to grant access to resources. Explanation
-
Explanation of group types
Reference Will highlight only non-common interesting groups here.
- Power users - Legacy group released to allow backward compatibility with XP applications, doesn't nothing in Vista and later.
- Remote Desktop users - RDP login
- Offer Remote Assistance Helpers - Allow unsolicited remote assistance help
- Network Configuration Operators - Change TCP/IP settings, renew/release DHCP info.
- Performance Log Users - Manage performance, logs, alerts on computer, local and remotely.
- Performance Monitor Users - Monitor performance counters local and remotely.
- IIS_USRS - Automatically created by IIS to run, with best selected settings. Don't need to touch.
- Replicator - Used by AD on DC for replication. Don't add users to group. Not used on Win 7.
- Distributed COM Users - Members can start, activate, use DCOM objects.
- Cryptographic operators - Members can change system level cryptographic settings. Will not need to touch.
-
When a server becomes AD, local accounts are disabled, local groups are migrated to Builtin folder on AD. This gets replicated to all other ADs but unavailable to domain computers. All DCs share same Builtin.
-
Server operators
- Purpose: Server maintenance of DCs only, no AD administration.
- Default: no member.
- Rights: Can login, create/delete shared resources, start/stop services, backup/restore HDD, format and shutdown DCs.
-
Account operators
- Purpose: AD administration only, cannot manage accounts of Administrators, Server operators, or modify user rights.
- Default: No members
- Rights: Create, modify, delete domain accounts.
-
Print operators
- Purpose: Manage printer objects in AD
- Default: No members
- Rights: Manage all printer objects in AD, and printers connected to DC. Can shutdown DC.
-
Incoming forest trust builders
- Purpose: Create incoming one-way trust to forest.
-
Certificate Service DCOM Access
- Purpose: Members can obtain certificates from CA.
-
Windows Authorization Access Group
- Purpose: No idea what this does.
-
Enterprise Admins
- Purpose: Most powerful admin group in AD.
- Default: Admin account for forest root domain.
- Rights: Sits in root domain, but members can come from any domain. Can add/remove domains in forest. Added to all domain admin groups in forest. Forest-wide config.
-
Schema admin
- Purpose: Modify the AD schema.
- Default: Admin account for forest root domain.
- Rights: Defines schema, which affects all domains in forest.
-
Domain guest
- Rights: Unlike domain users, they have no login rights or automatic membership in local guest group.
-
Domain controllers
- Purpose: Contains all domain controllers for group less RODCs.
-
RODC
- Default: All RODCs automatically gets placed here.
-
Enterprise RODCs
- Purpose: Exist only on root domain.
- Default: No members.
-
Denied RODC password replication group
- No idea WTF is this.
-
DNS Admins
- Purpose: DNS administration
- Default: No idea.
- Rights: Start/stop DNS service
-
Group Policy Creators Owners
- Purpose: Modify domain group policy.
- Default: Domain admin.
- Rights: Create, edit, delete GPO in domain.
-
Cert publisher
- Purpose: If CA is used, can store certs in AD for use in computers.
-
RAS and IAS Servers
- Purpose: No idea what this does.
Note: These exist on local computer only, with same SID on all Windows PCs.
- Anonymous logon - Login without username/password
- Authenticated users - Users authenticated by DC or local.
- Everyone - Interactive, network, authenticated users included. Pre-Windows 2000, included Anonymous logon.
- Interactive - Users logged on locally, include RDP.
- Remote Interactive - RDP logon only, subset of Interactive.
- Local Service - The Local Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session with anonymous credentials. The name of the account is
NT AUTHORITY\LocalService
. This account does not have a password. - Network Service - The Network Service account is similar to an Authenticated User account. The Network Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Network Service account access network resources by using the credentials of the computer account. The name of the account is
NT AUTHORITY\NetworkService
. This account does not have a password. - Local System - This is a service account that is used by the operating system. The LocalSystem account is a powerful account that has full access to the system and acts as the computer on the network. If a service logs on to the LocalSystem account on a domain controller, that service has access to the entire domain. Some services are configured by default to log on to the LocalSystem account. Do not change the default service setting. The name of the account is LocalSystem. This account does not have a password. AKA
NT AUTHORITY\SYSTEM
- Network - This group implicitly includes all users who are logged on through a network connection. Any user who accesses the system through a network has the Network identity. This identity allows only remote users to access a resource. Whenever a user accesses a given resource over the network, the user is automatically added to the Network group. Membership is controlled by the operating system.
-
AGUDLP - Add the Accounts to Global group, add the Global group to Universal group, add Universal group to Domain Local group, then assign permissions to Domain Local group.
-
AGDLP - Add the Accounts to Global group, Add the Global group scope to Domain Local group, then assign permissions to Domain Local group.
-
UG members requite GCS to login to network, if none available login not possible unless caching is enabled.
-
Cache is updated every 8 hrs, and is used only when GCS is unavailable. Enabled in AD Sites and services.
-
A way to create AD users for external parties not in organisation, without assigning SID. Instead of creating new User, create new Contact in ADUC. This creates a common identity for corporate users to refer to instead of creating separate identities for each user in their address book.
-
Can be put in AD groups, but Security tab disabled in Server 2016; no resource access granted.
- Works by having two SIDs for admin account. One user, one administrator.
- It's an AD user account created to run a particular service.
- Typically passwords not set to expire.
- Given minimum rights, typically just domain user rights.
- Implementation
- Create
ServiceAccounts Global group
in ADUC to hold all service accounts - Add service account as member.
- Start
services.msc
, find service, go to Log On tab to change to service account log on. - Restart service and done.
- Create
-
Similar to service accounts, except that passwords are 120 chars long randomly set and automatically changed every 30 days, like AD computers.
-
They are bound to one AD computer, but can be placed into groups to give access to network resources.
-
Check supported software for managed service account. Google for guides on how to set up.
-
Creation of managed service account in PS:
Import-Module ActiveDirectory
New-ADServiceAccount -name [MSA-name] -Enable $True
Add-ComputerServiceAccount -Identity [AD computer] -ServiceAccount [MSA-name]
Install-ADServiceAccount -Identity [MSA-name]
- Then go to software, and enter
Domain\[MSA-name]$
, include dollar sign so Windows can find account. Leave password blank.
-
Join computers to domain without access to DC, whether due to unavailable or not yet set up networking.
-
Use cases:
- Automated installs of Windows. Computer can join domain during Windows installation without network access.
- If RODC in use: While pending replication with writable DC, RODC can store domain join changes via offline domain join. However, logins or network access is granted only once changes are passed to writable DC and replicated to RODC.
- Non-admin can add computer to domain without username/password, as long as have the domain join text file. Login not available until DC network access is granted. Reference
- OUs are used to organise AD objects (users, computers, other OUs) otherwise AD database will just have one large folder of objects, without any organisational structure.
- Unlike groups, objects can only belong to one OU; similar to how files are stored in folders.
- GPO is applied to OUs and not groups.
- OU is also used for delegation of administration. Can grant admin rights to manage just one OU within a domain instead of the entire domain.
- Apart from Domain Controllers OU containing list of DCs, none of the default OUs allow GPO to be applied.
- Shadow groups are groups which mirror OU membership so permissions can be granted/denied based on this list.
- Default OUs
- Builtin - Default accounts moved from local DB to AD DB after promotion to DC.
- Users - Default location of user account if created by software.
- Computers - New computers which joined domian added here.
- Domain controllers - Only OU where GPO is applicable.
- LostAndFound - Orphaned objects go here. For eg, objects created but deleted before it gets replicated to all the DCs are moved here. Check occsaionally to see if objects here should be moved elsewhere.
- OU - Managed by user setting doesn't grant any permissions. Just there for admin purposes.
- Allow admins to delegate control or admin rights for certain tasks to specific users eg. reset/change passwords for users in a given OU.
- Right-click OU -> Delegate control, follow wizard.
- Delegation of control wizard doesn't do anything which the Security tab of the OU can't do. Just a wizard which simplifies permissions.
AD CLI tools - Some selected commands which work in cmd
Reference
DSAdd
- Adds AD object.DSGet
- Retrieves information on AD object.DSMod
- Modify AD object, eg. changing user password or force them to change passwords on next logon.DSRM
- Deletes AD object.DSQuery
- Searches AD with given parameters.CSVDE
- Import/export AD DB in CSV format.LDIFDE
- Import/export AD DB in LDF format.
- Used for inter-forest, intra-forest migration and SID history preservation for migrated users.
- Advised not to install on DC but instead member server.
- Check online or watch video for details.
Skipped. Remote administration tools. Not applicable.
-
Registry developed by Microsoft as a centralised replacement for text config files. This is where all changes are reflected.
-
Changes made to Registry, however cannot be rolled back easily.
-
GP developed to allow easy rollback of these Registry changes.
- GP directory in Registry in
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions
- GP directory in Registry in
-
GP is created on AD, domain Client PCs download them. Non Windows clients can choose not to download GP. GP once downloaded is processed/applied by Client Side Extensions
-
Group Policy Management Editor -> GP Management Editor -> Right-click Filter Options:
- Managed: Yes means if GP is removed, any changes made is reverted. Otherwise it stays.
- When Enabled, it is applied immediately no need to be saved.
- Difference between Disabled and Not Configured. Suppose GP disables a default behaviour, Enable disables it, Disabled enables default behaviour while Not Configured lets other GP decide. Explanation. Also see explanation in Video MCITP 70-640 - Group Policy Processing Order 12:00 and GP processing order below.
-
In Group Policy Management Editor, any settings under Policies user is forced to have. Any settings under Preferences is optional to the user; ie. does not overwrite what the user configured.
-
Difference between Computer Configuration and User Configuration:
Computer configurations only apply to computer objects, user configurations only apply to user objects. To phrase it another way, a GPO containing only computer configurations applied to an OU containing only users will have no effect whatsoever. A GPO containing only user configurations applied to an OU containing only computer objects will have no effect - unless loopback policy processing mode is enabled, which is a different story - but even then, the user configurations will only apply to users logging into computers in that OU. Source
- Administrative Templates. Contains the policy templates created by Microsoft to apply across AD users and computers groups. Hover above folder to see whether it is retrieved from shared folder on SYSVOL or local computer.
- Introduced in Windows Vista and Windows Server 2008, ADMX files — sometimes called Administrative Template XML-Based files — specify which registry keys in the Windows Registry are changed when a certain Group Policy setting is changed. For example, one ADMX file might prevent users from accessing Internet Explorer. The information for this block is located in the ADMX file which in turn is reflected in the registry. Source
- To install latest ADMX templates, search for "ADMX templates for Server 2016" then download.
- Local PC ADMX path - C:\Windows\PolicyDefinitions.
- To load Administrative Templates, copy PolicyDefinitions folder where you downloaded in (ii) to
\\DC-share\SYSVOL\domain\Policies
. Verify in GP Management Editor -> Administrative Templates, hovering that it says "retrieved from central store"
- GP applied in this order: Local -> Site -> Domain -> OUs -> Child OU's. Applied from left to right. Mnemonic L-S-D-OU-Child.OU
- Later ones applied overwrite the earlier ones. GP applied upon login. Don't need to save, just logout and back in.
gpedit.msc
to edit the local ones.- Configure site-level GP:
- GP Management -> Right-click GPO -> New (name the GPO)
- Right-click Sites -> Show Sites -> Select sites to show
- Right-click selected site -> Link existing GPO -> Select GPO created in (i) above.
- Right-click GPO under selected site -> Edit and configure GP. Logout and login again to take effect.
- Configure OU-level GP:
- GP Management -> Select OU -> Create a GPO in this Domain and link it here.
- Right click new GP on right hand window and Edit
- Search for policy -> Configure -> Enable. Logout and login again.
- GP is processed backwards for Link Order, eg. 2 first then 1.
- Computer side GP applied first, then User side. This allows User GP to overwrite Computer GP, although there aren't many overlaps between Computer and User GPs.
- GP inheritance from higher-level order can be blocked. Eg. Domain, OU, Child OU (blocked), Child-Child-OU. Domain and parent OU GP's are not applied, but from Child OU onwards allowed.
- Configuration: Right-click OU -> Block Inheritance (white exclamation on blue icon appears)
- Enforced GP are applied in the reverse order of default GP application. ie. S-D-OU(blocked)-Child.OU -> Child.OU-D(enforced)-S(enforced). This prevents lower OU admins from blocking higher level GP from being enforced.
- Configuration: Right-click GP -> Enforced (Lock icon appears)
- Avoid using blocking/enforcing GP because it adds complexity.
- Instead right-click OU -> Link an Existing GPO -> Select GPO (OK)
- Delete domain wide GP if not needed (delete the shortcut directly under domain).
- Verify which OU's have a specific GP applied: Go to Group Policy Objects -> select GP -> Look at Scope tab on RHS window
- Verify which GP's are applied on a specific OU: Select OU -> Look at Linked Group Objects tab and Group Policy Inheritance
-
Typically when users login to a PC, the GPOs applied to that session will be from their user OU's. However, in some circumstances such as training kiosks you don't want the user's GPO settings to apply but rather from the Users OU where the computer is located in AD.
-
Replace mode - What is configured in GPO User Configuration where computer is located replaces the GPO in the user's OU.
- Configuration: Go to GPO where computer is stored in. Then enable via this node:
Computer Configuration\Policies\Administrative Templates\System\Group Policy
- Configuration: Go to GPO where computer is stored in. Then enable via this node:
-
Merge mode - GPO in user's OU is applied first, then the User Configuration in the computer's OU is applied and overwrites those settings which conflict in user's OU.
- Same as Replace, just choose Merge.
-
- Doesn't overwrite GP but can be used to push down files/folders to workstations eg. desktop wallpaper containing messages.
- Supports item-level targeting - OS version, security groups, domain, disk space, IP range. Applicable only to users/computers who meet these criteria
gpupdate /force
to download group policies from DC instead of relying on cache.
- Templates for GPs. Created by Microsoft as suggested GP template settings for workstation/server roles.
- Starter GPOs only have Administrative Templates.
- Can copy GPOs and paste to duplicate template.
- Can backup and import GPO settings
- GP Management -> Group Policy Objects, right-click Backup, specify name in Description
- Importing steps: Right click GPO -> Import Settings -> select exported GPO
- When applying GPO for each OU it is applied to, it is possible to specify whether to apply either the Computer or User configuration settings or both.
- GP Management -> OU -> GPO shortcut -> Details tab -> GPO Status - This is for applying Computer/User config settings.
- Verify by checking the Settings tab
- It is also possible to specify at a more detailed level which Global groups this policy should affect only, or even to apply WMI filters to select computers with specific settings.
- GP Management -> OU -> GPO shortcut -> Scope tab -> Security filtering - Specify to which security groups this should apply to.
- It also possible to exclude GPO from being applied to a users security group under an OU. Note that if a user is allowed access under one GPO but denied under another, the denied one overwrites access for the allowed one.
- GP Management -> OU -> GPO shortcut -> Delegation tab -> Advanced button -> Add group -> Select Deny for Read and 'Apply group policy'
- All GPOs consist of two parts: Group Policy Container (GPC) and Group Policy Template (GPT)
- GPC is an AD object and stored in the AD DB and replicated via AD replication (same as User/Computer accounts)
- GPT is collection of files stored in the shared SYSVOL folder and replicated via FRS or DFS.
- Because these two are replicated differently, replication sync errors can occur; check Windows Event Viewer for replication errors.
- GP Management -> OU -> GPO shortcut -> Details tab Check user/computer version are same for AD and Sysvol replication. Note the Unique ID for GPO as well.
- GPT:
\\AD\SYSVOL\<domain>\Policies\<Unique ID>\GPT.ini
<- Revision number of the GPT in decimal. Convert to hex, 1st hex is user config version, last hex number is computer config version number eg. 0x20009. User configuration version 2, computer configuration version 9. - GPC: ADUC -> View Advanced Features -> System -> Policies -> Unique ID -> Properties -> Attribute Editor tab -> versionNumber
- GPT:
- This allows you to modify the local group membership of computers in an OU. In practical terms this means you can add specific Global groups to Computer accounts of an OU to have local admin rights. Note that this cannot be used for Domain groups since Microsoft intended this for local group membership only.
Managing membership of Domain Groups by using Restricted Groups Microsoft does not support using Restricted Groups in this scenario. Restricted Groups is a client configuration means and cannot be used with Domain Groups. Restricted Groups is designed specifically to work with Local Groups. Domain objects have to be managed within traditional AD tools. Therefore, we do not plan currently to add or support using Restricted Groups as a way to manage Domain Groups.
- Edit GPO in GP Management -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups -> right-click, Add Group -> Specify local group name
- Members of this group: Add/remove members to group.
- This group is a member of: Allows you to include new group as sub-group of another local group. Eg. Labadmins group can be a member of local Administrators group.
- Local groups can also be managed with GP Preferences.
- GP preferences are overwritten by GP Restricted group settings (above) if both are active.
- Edit GPO -> User Configuration -> Preferences -> Control Panel settings -> Local Users and Groups -> Right-click New local group/user -> Configure
- Verify that local group changes are made with Edit local users and groups
-
Types of software deployment
- Publishing - Allows user to choose whether to install/uninstall software via Control Panel. Able to install on double-clicking associated file.
- Assigning computer - Auto install software on start up for all users. User cannot uninstall.
- Assigning user - Auto install software on all computers the user logs on to. Can also install via opening associated file.
-
Software installer packages
- MSI
- Contains all files and config, as well as where to create shortcuts etc. Small database containing all required details.
- Able to mass automate via GP with default configuration options.
- MST - Transform file
- Allows customisation of MSI packages when installed such as shortcuts, install dir, choosing components etc.
- MSP - Patch file
- Can use only after MSI installed.
- Updates or service packs
- ZAP - deprecated pre MSI package
- Text script which GP uses to run. GP cannot detect if installed succesfully.
- Doesn't support elevation to another set of creds to install software; installing user needs to have all rights required.
- Can install only once; even if that fails GP will not attempt to reinstall again.
- No rollback supported.
- MSI
-
Configure slow link detection at Computer Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy slow link detection. This will prevent software from being installed over a slow network link.
-
Steps to install software via GP
- Share the folders containing the MSI files with read-only access.
- Edit GP under the relevant OU -> GP Management editor
- Two options: Assigning computer vs publishing/assigning to user
- Assigning computer - Computer Configuration -> Policies -> Software Settings -> Software Installation -> Advanced (always select this). Deployment tab -> Uninstall application when GPO no longer applies (deleted or permissions changed). Software installed on all computer accounts under this OU.
- Assigning/Publishing to user - User Configuration -> Advanced -> Tabs
- Deployment tab - select Publish or Assign to user
- Modifications tab - apply MST transform file to MSI packages
- Upgrades tab - Used for providing software updates. Select Required upgrade for existing packages to mandate upgrades
- Right-click name, select All tasks
- Redeploy application - Re-installs application if needed
- Remove - Either uninstall software or allow users with installed to continue using software and prevent new installation
- If software is published to user, they can install by going Control Panel -> Programs & Features -> Install a program from the network (left panel). Install as per wizard
- Block specific software from running, or allow user to run specific software versions only.
- Running in audit mode allows admin to collect data on how often software is used.
- Fingerprints software by
- Publisher digital signature (version ID)
- Hashed value for those w/o digital signatures (version specific only)
- Path, where software is stored.
- Edit GPO under Group Policy Management
- Enable Application Identity service in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services -> Service Startup mode (automatic)
- Then configures rules at Security Settings -> Application Control Policies -> AppLocker -> Configure Rule Enforcement
- Generate rules : Executable Rules -> Automatically Generate Rules
- If file is not signed, create rule by either file hash or file's path
- Reduce number of rules by grouping similar files : Have wizard analyze rules to see if similar rules can be grouped under fewer rules.
-
Create New Rule for manual rule creation
- Browse to executable location.
- Drag slider up to make rule less specific
- Add exception if necessary (eg. block all software versions except one)
-
When rule is applied, popup with message
Your system administrator has blocked this program.
-
When GP changes are made, by default AD makes them on the DC holding the role of PDC emulator.
-
This can be changed in GP Management -> Right-click domain -> Change domain controller.
-
Regardless of which DC where changes are made, it needs to be replicated to DC which the client is authenticating off.
-
Can manually force DC replication by
- AD Sites & Services -> Sites -> Servers -> NTDS Settings -> Right-click Replicate Now
cmd.exe
- AD replication:
repadmin /SyncAll
. Check withdcdiag
- FRS SYSVOL replication:
ntfrsutl forcerepl <local computer name> /r "Domain System Volume (SYSVOL share)" /p <DNS name of target DC to replicate to>
- DFSR SYSVOL replication:
Dfsrdiag SyncAll /Partner:<remote computer> /RGname:"Domain System Volume" /time:<how long to ignore current replication schedule>
- AD replication:
-
To ensure GP is applied after network is available and computer started up, go to:
Computer Configuration\Policies\Administrative Templates\System\Logon\Always wait for the network at computer startup and logon
-
Once GP updated, domain computer will refresh and download GPs certain intervals between 90-120 min. Change refresh rate at
Computer Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy Refresh interval for computers
-
Change refresh rate for DCs:
Computer Configuration\Policies\Administrative Templates\System\Group Policy\Group Policy Refresh interval for domain controllers
-
Manual gpupdate:
gpupdate /force
gpupdate /target:<USER or COMPUTER>
- gpupdates for only computer / usergpupdate /? to see all options
-
Allows you to see exactly which GPO's have been applied for each user and computer or simulate the effects of GP for effecting certain changes. This avoids having to look through all the possible settings and determining which apply to your computer.
-
Requires admin rights, ports 135,445 and WMI service WMI Performance Adapter on target computer (not DC) to be running.
- Enable Inbound Rules in Windows Firewall rule for:
- Remote Event Log Management(NP-In)
- Remote Event Log Management(RPC)
- Remote Event Log Management(RPC-EPMAP)
- Windows Management Instrumentation (WMI-In)
- Enable Inbound Rules in Windows Firewall rule for:
-
To view GP results, go Group Policy Management -> Right-click Group Policy Results -> GP Results Wizard
- You can view policy settings for user only if they have logged onto the target computer before.
- Policy Events tab tracks all the events which occured such successful/failed application of GP.
-
To view simulated GP results, go GP Mgmt -> Right-click GP Modeling -> GP Modelling Wizard
- Select User, Computer to see effects of policies on those.
- Enable Loopback processing if you want to see GPOs applied based just on the Computer object in AD. Reference
- Select AD site to test applying GPOs from that site.
- User location, Computer location lets you simulate the effects of moving around the User, Computer account to different OUs.
- Add/remove accounts from security groups.
- Can also specify WMI filters.
-
To view RSOP on
cmd.exe
withgpresult
/r
- displays RSOP summary/v
- Verbose RSOP results/scope <user> or <computer>
- to limit results to specific scope/x
- outputs to XML/h
- output to HTML
-
All computers have local security policy, a subset of local group policy. DCs' local account settings are disabled and are instead managed by Default Domain Controllers' Policy in AD
-
Local security policies accessible via Local GP editor -> Computer Configuration -> Windows Settings -> Security Settings or Local Security Editor (which has subset of local GP editor)
-
Local security policies are used when the computer cannot join a domain due to security restrictions eg. DMZ server accessible from Internet.
-
Export local security policy: Local Security Policy -> Right-click Security Settings -> Export policy (INF file)
-
Import local security policy: Local Group Policy Editor -> Computer Configuration -> Windows Settings -> Right-click Security Settings -> Import Policy
-
Compare imported INF local security policy by going to MMC -> File -> Add/Remove Snap-In -> Security Configuration and Analysis then General steps are: 1) Create DB or overwrite existing one 2) Import INF files to DB 3) Select to compare DB with existing computer.
- Right-click Security Configuration and Analysis -> Open Database -> type in new database name to create -> Import Template (INF)
- Right-click Security Configuration and Analysis -> Analyze Computer now -> save log file -> Inspect the elements under Security Configuration and Analysis to see differences in local computer and created database
- To apply settings from imported INF, right-click Security Configuration and Analysis -> Configure Computer Now -> save error log file
sec-edit
/validate <path to INF>
- Checks validity of INF/Import /db <path to .sdb file> /cfg <path to INF> /Overwrite
- Imports saved INF to specified DB and overwrite it./analyze /db <path to .sdb file>
- Compare DB data settings with existing computer settings
-
Hardening, done by disabling unwanted services, closing unused ports and protocols is done to reduce the attack surface from potential hackers
-
Security Configuration Wizard consists of several sections.
- Services - Select services/protocols needed on server.
- Network (Windows firewall) - Enable/disable DHCP, ipv6, ICMP etc.
- Registry settings - SMB signing, NTLM settings
- Audit policy - Determine when certain Windows events are logged such as file access/modification or user logons etc.
-
Security policy can be saved as XML to apply elsewhere.
-
Import Security policy can be used on either local or remote servers but beware of locking out access from remote computer after security policies are applied.
-
Rollback last applied security policy is available as option on Security Configuration Wizard.
- Import saved security policy to GPO with command:
scwcmd transform /p:"<path to XML>" /g:"<GPO name>"
. The GPO is now found in GP Management -> Domain name -> Group Policy Objects. It can now be linked to an OU to apply the settings.
-
Auditing controls what is logged in Windows Event Viewer, eg. access or logon attempts.
-
ACL's used to control access and auditing. ACL's consist of ACE's or access control entries Reference
- Discretionary ACL controls read/modify/execute rights for users.
- System ACL allows administrators to log attempts to access a secured object.
-
Configure auditing: GP Management -> Right-click GPO -> Edit -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy
-
Audit policy settings - Most audit settings are configured to record only successful access. Some common ones listed below. See list here
- Audit account logon events - Records logon for user via AD or local login
- Audit Account Management - Records changes to accounts such as creating/changing user accounts and password resets.
- Audit directory service access - Changes to AD objects are recorded
- Audit logon events - Records logins after user is authenticated by AD login, eg. file share access after interactive login. A lot more info compared to audit account logon events. Info such as how long logged in and what was accessed.
- Audit object access - Determines whether to audit the event of a user accessing an object--for example, a file, folder, registry key, printer, and so forth--that has its own system access control list (SACL) specified.
- Audit policy change - Determines whether to audit every incident of a change to user rights assignment policies, audit policies, or trust policies.
- Audit privilege use - Determines whether to audit each instance of a user exercising a user right eg. changing system time, taking ownership of files/folders.
- Audit process tracking - Tracks detailed information for events such as program activation, process exit, handle duplication, and indirect object access. Generates a lot of logs when enabled.
- Audit system event - Tracks when a user restarts or shuts down the computer or when an event occurs that affects either the system security or the security log
-
Event Viewer can record what is changed rather than just a change which occurred, to enable run
cmd
with:AuditPol /Set /SubCategory:"Directory service changes" /Success:Enable
-
Access events added by auditing in Event Viewer -> Windows Logs -> Security.
- Event Viewer not intuitive, changes in settings are reflected as Value Deleted and Value Added. Have to open multiple events to understand changes.
-
Found in GP Management Editor -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies
-
Explanation of some settings (non-intuitive settings)
- Password Policy
- Enforce password history - Set no. of passwords stored for each user to prevent reuse. Default 24
- Min password age - Min time a password needs to be in use before changing. Prevent users from cycling through 24 passwords just to reuse old pw. Default 1 day.
- Note: Settings under Account tab in ADUC will overwrite settings on Domain level.
- Account lockout policy
- Account lockout duration - Automatically unlock account after X amt of time.
- Note that built-in Administrator account cannot be locked out, instead login attempts are delayed.
- Note that Windows 2003 and above will compare wrong passwords entered with previous passwords used, if match will not lockout account.
- Kerberos policy
- Enforce user logon restrictions - Force Key Distribution Center (KDC) to validate every request against the user rights policy of the account before creating Kerberos ticket. Worth turning it off on slow networks because otherwise ticket creation is held back until validation.
- Maximum tolerance for computer clock synchronisation - Disallow requests with time stamps differing from DCs by more than X min; mitigates replay attacks.
- Password Policy
-
Able to set different password policies for security groups as opposed to just domain wide.
-
Password settings object (PSO) contain password policy settings for OU.
-
When multiple PSO's used, PSO with lowest priority/value will be applied. 1 is lowest. If multiple PSO's have lowest priority, PSO with lowest GUID will be applied.
-
Use ADSI edit to modify AD database.
- Right-click ADSI edit -> Connect to -> Navigate domain -> CN=System -> right-click CN=Password Settings Container -> New Object
- Configure password policy as required.
- When done, right click PSO -> Properties -> Attribute Editor -> msDS-PSOAppliesTo -> Add Windows Account -> Add security groups
- This will apply configured PSO to selected group
- Verify that PSO applies to sample users by going to Attribute Editor tab -> Filter Constructued -> msDS-ResultantPSO. Check that PSO name is in the value of the LDAP entry
-
It is also possible to apply password policy objects to an OU by creating a shadow security group mirroring the OU membership and having a PS or VBS script automatically update the membership regularly. See video 13min onwards
- This allows administrators to deny certain access rights to specific groups
- Options are:
- Deny access to this computer from the network (doesn't block RDP)
- Deny log on as a batch job - Jobs that are run with task scheduler using the denied user will be blocked.
- Deny log on as a service - Prevent user account from being used to run services.
- Deny log on locally
- Deny log on through Remote Desktop Services