Archive for Active Directory

Using WMI Filters in Group Policies

April 1, 2015 Active Directory No comments

filtericon

What are WMI Filters?

Windows Management Instrumentation (WMI) filters allow you to dynamically determine the scope of Group Policy objects (GPOs) based on attributes of the target computer. When a GPO that is linked to a WMI filter is applied on the target computer, the filter is evaluated on the target computer.

When a GPO that is linked to a WMI filter is applied on the target computer, the filter is evaluated on the target computer. If the WMI filter evaluates to false, the GPO is not applied (except if the client computer is running Windows 2000, in which case the filter is ignored and the GPO is always applied). If the WMI filter evaluates to true, the GPO is applied.

WMI makes data about a target computer available for administrative use. Such data can include hardware and software inventory, settings, and configuration information. For example, WMI exposes hardware configuration data such as CPU, memory, disk space, and manufacturer, as well as software configuration data from the registry, drivers, file system, Active Directory, the Windows Installer service, networking configuration, and application data.

GPOs are processed in the following order

The WMI filter is a separate object from the GPO in the directory.

To apply a WMI filter to a GPO, you link the filter to the GPO. This is shown in the WMI filtering section on the Scope tab of a GPO. Each GPO can have only one WMI filter, however the same WMI filter can be linked to multiple GPOs.

WMI filters, like GPOs, are stored on a per-domain basis. A WMI filter and the GPO it is linked to must be in the same domain.

  •     The local GPO is applied.
  •     GPOs linked to sites are applied.
  •     GPOs linked to domains are applied.
  •     GPOs linked to organizational units are applied. For nested organizational units, GPOs linked to parent organizational units are applied before GPOs linked to child organizational units are applied

A practical GPO and WMI example.

We had a requirement to have separate GPOs for Windows 7 Internet Explorer 10 users than Windows XP Internet Explorer 8 users. This is where we can have a policy which is filtered by Windows 7.

  • First of all log into your Group Policy Management Console
  • Create a new Group policy which will need to be assigned at the domain level, OU level or sub OU level depending on your design.
  • Modify the Group Policy with the settings you require
  • Now have a look at where WMI Filters are located by scrolling down to the bottom of the GPMC

wmi1

  • Right click and select New

wmi2

  • Put in a name and description

wmi3

  • Next Click Add and you will get a new box where we can then add our WMI filter code

wmi4

It is probably worth talking a little about the Namespace and WMI language at this point.  The queries are written using the WMI Query Language (WQL), a SQL-like language. Queries can be combined with AND and OR logical operators to achieve whatever effect the administrator wants. Each query is executed against a particular WMI namespace. When you create a query, you must specify the namespace. The default is root\CIMv2, which is appropriate for most WMI queries.

I downloaded a small free program from Microsoft called WMI Code Creator. The tool also allows you to browse through the available WMI namespaces and classes on the local computer to find their descriptions, properties, methods, and qualifiers.

As an example below, I can look at the Operation System properties and find the version and also the name if I look at the Caption Properties

wmi5

Note: This piece of software is useful for delving into the WMI information but you need to be able to use the WMI query in a way Active Directory understands.

SELECT [property] from [wmi class]

  • Have a look at the table below. Both Windows Server 2012 and Windows 8 return version numbers that begin with 6.2. To   differentiate between the client and server versions, include the clause to check the ProductType field. This value returns 1 for client versions of Windows such as Windows 8, 2 for server versions of Windows operating as domain controllers, and 3 for server versions of Windows that are not operating as domain controllers.

wmi6

  • You can also create combination filters when required by your design. The following table shows query statements for common operating system combinations.

wmi7

  • As an example we wanted our policy to apply to Windows 7, Windows 8 and Windows 8.1 so this was our filter

wmi8

  • Click Save and go back to your Group Policy
  • Click on Scope and look at the bottom of the Scope Page where you will see WMI Filters
  • Here you will need to select your WMI Filter and apply it

wmi10

  • Next click start run and type gpupdate /force on your DC to push out the settings.
  • If you want to test that your GPO and WMI filters work then you can go back to your Group policy management console and look right down the bottom again where you have an option – Group Policy Results

wmi11

  • Right click and select Group Policy Results wizard and you can run through this and select a target computer and user to test whether then WMI works.
  • At the end you will get a Summary, Details and Policy Events and you want to scroll down and check Details where it will say whether the WMI Filter came out as True or False!

wmi13

  • And that’s it. It’s worth having a look through the many ways you can filter and write queries.

An interesting point to finish

What takes precedence when multiple, conflicting GPOs apply to the same OU?

“Links to a specific site, domain, or organizational unit are applied in reverse sequence based on link order. For example, a GPO with Link Order 1 has highest precedence over other GPOs linked to that container.”

What takes precedence when multiple, conflicting enforced GPOs apply to the same OU?

Setting a GPO to enforced effectively moves it to the end of the processing order, meaning it always wins. If you have multiple conflicting Enforced GPOs they go in reverse order. (The ‘higher’ one in the OU structure wins,) But if it ever got that complex, you would need to rethink your overall GPO strategy in the long term.

Standard GPO Inheritance Rules in Organizational Units

Any unconfigured settings anywhere in a GPO are ignored, and only configured settings are inherited. There are three possible scenarios:

  • A higher-level GPO has a value for a setting, and a lower-level GPO does not.
  • A GPO linked to a parent OU has a value for a setting, and a GPO linked to a child OU has a non-conflicting value for the same setting.
  • A GPO linked to a parent OU has a value for a setting, and a GPO linked to a child OU has a conflicting value for the same setting.

If a GPO has settings configured for a parent organizational unit and the same policy settings are unconfigured for a child organizational unit, the child inherits the parent’s GPO settings. That makes sense.

If a GPO has settings configured for a parent organizational unit that do not conflict with the settings in a GPO configured for a child organizational unit, the child organizational unit inherits the parent GPO settings and applies its own GPOs as well. A good example of this is two logon scripts; these scripts don’t conflict, so both are run

If a GPO has settings configured for a parent organizational unit that conflict with the same settings in another GPO configured for a child organizational unit, the child organizational unit does not inherit those specific GPO settings from the parent organizational unit. The settings in the GPO child policy take priority

Understanding Active Directory Domain Services (AD DS) Functional Levels

March 1, 2014 Active Directory 2 comments

level

What are Functional Levels?

Functional levels determine the available Active Directory Domain Services (AD DS) domain or forest capabilities. They also determine which Windows Server operating systems you can run on domain controllers in the domain or forest. However, functional levels do not affect which operating systems you can run on workstations and member servers that are joined to the domain or forest.

When you deploy AD DS, you need to set the domain and forest functional levels to the highest value that your environment can support. This way, you can use as many AD DS features as possible. For example, if you are sure that you will never add domain controllers that run Windows Server 2003 to the domain or forest, select the Windows Server 2008 functional level during the deployment process. However, if you might retain or add domain controllers that run Windows Server 2003, select the Windows Server 2003 functional level.

When you deploy a new forest, you are prompted to set the forest functional level and then set the domain functional level. You cannot set the domain functional level to a value that is lower than the forest functional level. For example, if you set the forest functional level to Windows Server 2008, you can set the domain functional level only to Windows Server 2008. In this case, the Windows 2000 native and Windows Server 2003 domain functional level values are not available. In addition, all domains that you subsequently add to that forest have the Windows Server 2008 domain functional level by default.

You can set the domain functional level to a value that is higher than the forest functional level. For example, if the forest functional level is Windows Server 2003, you can set the domain functional level to Windows Server 2003or higher.

Guidelines for raising domain and forest functional levels

  • You must be a member of the Domain Admins group to raise the domain functional level.
  • You must be a member of the Enterprise Admins group to raise the forest functional level.
  • You can raise the domain functional level on the primary domain controller (PDC) emulator operations master only. The AD DS administrative tools that you use to raise the domain functional level (the Active Directory Domains and Trusts snap-in and the Active Directory Users and Computers snap-in) automatically target the PDC emulator when you raise the domain functional level.
  • You can raise the forest functional level on the schema operations master only. Active Directory Domains and Trusts automatically targets the schema operations master when you raise the forest functional level.
  • You can raise the functional level of a domain only if all domain controllers in the domain run the version or versions of Windows Server that the new functional level supports.
  • You can raise the functional level of a forest only if all domain controllers in the forest run the version or versions of Windows Server that the new functional level supports.
  • You cannot set the domain functional level to a value that is lower than the forest functional level, but you can set it to a value that is equal to or higher than the forest functional level.
  • With versions of Windows Server that are earlier than Windows Server 2008 R2, you cannot roll back or lower a functional level under any circumstances. If you have to revert to a lower functional level with a version of Windows Server that is earlier than Windows Server 2008 R2, you must rebuild the domain or forest or restore it from a backup copy.
  • After you set the domain functional level, you cannot roll back or lower the domain functional level except in the cases listed in the following table. The domain functional level can be lowered only by using Windows PowerShell

Rollback

  • Make sure replication is working properly

Checking Replication

  • repadmin /replsum

replication1

  • repadmin /showrepl

replication2

  • repadmin /bridgeheads

replication3

  • dcdiag /v (checking overall health of the domain)

replication4

Checking what Domain Controllers and FSMO roles you have

fsmo

Features available at Forest Function Levels

Windows 2003

  • Domain rename
  • Linked-value replication. Linked-value replication makes it possible for you to change group membership to store and replicate values for individual members instead of replicating the entire membership as a single unit. Storing and replicating the values of individual members uses less network bandwidth and fewer processor cycles during replication, and prevents you from losing updates when you add or remove multiple members concurrently at different domain controllers.
  • The ability to deploy a read-only domain controller (RODC)
  • Improved Knowledge Consistency Checker (KCC) algorithms and scalability. The intersite topology generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than AD DS can support at the Windows 2000 forest functional level. The improved ISTG election algorithm is a less-intrusive mechanism for choosing the ISTG at the Windows 2000 forest functional level.
  • The ability to create instances of the dynamic auxiliary class named dynamicObject in a domain directory partition
  • The ability to convert an inetOrgPerson object instance into a User object instance, and to complete the conversion in the opposite direction
  • The ability to create instances of new group types to support role-based authorization.
    These types are called application basic groups and LDAP query groups.
  • Deactivation and redefinition of attributes and classes in the schema. The following attributes can be reused: ldapDisplayName, schemaIdGuid, OID, and mapiID.
  • Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability.

Windows 2008

All of the features that are available at the Windows Server 2003 forest functional level, but no additional features are available. All domains that are subsequently added to the forest, however, operate at the Windows Server 2008 domain functional level by default.

Windows 2008 R2

  • All of the features that are available at the Windows Server 2003 forest functional level, plus the following features:
  • Active Directory Recycle Bin, which provides the ability to restore deleted objects in their entirety while AD DS is running.
  • All domains that are subsequently added to the forest will operate at the Windows Server 2008 R2 domain functional level by default.
  • If you plan to include only domain controllers that run Windows Server 2008 R2 in the entire forest, you might choose this forest functional level for administrative convenience. If you do, you will never have to raise the domain functional level for each domain that you create in the forest.

Windows 2012

  • All of the features that are available at the Windows Server 2008 R2 forest functional level, but no additional features.
  • All domains that are subsequently added to the forest will operate at the Windows Server 2012 domain functional level by default

Windows 2012 R2

  • All of the features that are available at the Windows Server 2008 R2 forest functional level, but no additional features.
  • All domains that are subsequently added to the forest will operate at the Windows Server 2012 domain functional level by default

Features available at Domain Function Levels

Windows Server 2003

  • Universal groups for both distribution and security groups.
  • Group nesting
  • Group conversion, which allows conversion between security and distribution groups
  • Security identifier (SID) history
  • The domain management tool, Netdom.exe, which makes it possible for you to rename domain controllers
  • Logon time stamp updates
    The lastLogonTimestamp attribute is updated with the last logon time of the user or computer. This attribute is replicated within the domain.
  • The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects
  • The ability to redirect Users and Computers containers
    By default, two well-known containers are provided for housing computer and user accounts, namely, cn=Computers,<domain root> and cn=Users,<domain root>. This feature allows the definition of a new, well-known location for these accounts.
  • The ability for Authorization Manager to store its authorization policies in AD DS
  • Constrained delegation
    Constrained delegation makes it possible for applications to take advantage of the secure delegation of user credentials by means of Kerberos-based authentication.
    You can restrict delegation to specific destination services only.
  • Selective authentication
    Selective authentication makes it is possible for you to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest

Windows Server 2008

  • All of the default AD DS features, all of the features from the Windows Server 2003 domain functional level, and the following features are available:
  • Distributed File System (DFS) replication support for the Windows Server 2003 System Volume (SYSVOL)
    DFS replication support provides more robust and detailed replication of SYSVOL contents.
  • Beginning with Windows Server 2012 R2, File Replication Service (FRS) is deprecated. A new domain that is created on a domain controller that runs at least Windows Server 2012 R2 must be set to the Windows Server 2008 domain functional level or higher
  • Domain-based DFS namespaces running in Windows Server 2008 Mode, which includes support for access-based enumeration and increased scalability. Domain-based namespaces in Windows Server 2008 mode also require the forest to use the Windows Server 2003 forest functional level.
  • Advanced Encryption Standard (AES 128 and AES 256) support for the Kerberos protocol. In order for TGTs to be issued using AES, the domain functional level must be Windows Server 2008 or higher and the domain password needs to be changed.
  • Last Interactive Logon Information
  • Fine-grained password policies make it possible for you to specify password and account lockout policies for users and global security groups in a domain
  • Personal Virtual Desktops

Windows Server 2008 R2

  • All default Active Directory features, all features from the Windows Server 2008 domain functional level, plus the following features:
  • Authentication mechanism assurance, which packages information about the type of logon method (smart card or user name/password) that is used to authenticate domain users inside each user’s Kerberos token. When this feature is enabled in a network environment that has deployed a federated identity management infrastructure, such as Active Directory Federation Services (AD FS), the information in the token can then be extracted whenever a user attempts to access any claims-aware application that has been developed to determine authorization based on a user’s logon method.
  • Automatic SPN management for services running on a particular computer under the context of a Managed Service Account when the name or DNS host name of the machine account changes

Windows Server 2012

  • The KDC support for claims, compound authentication, and Kerberos armoring KDC administrative template policy has two settings (Always provide claims and Fail unarmored authentication requests) that require Windows Server 2012 domain functional level.

Windows Server 2012 R2

  • DC-side protections for Protected Users. Protected Users authenticating to a Windows Server 2012 R2 domain can no longer: Authenticate with NTLM authentication, Use DES or RC4 cipher suites in Kerberos pre-authentication, Be delegated with unconstrained or constrained delegation, Renew user tickets (TGTs) beyond the initial 4 hour lifetime
  • Authentication Policies: New forest-based Active Directory policies which can be applied to accounts in Windows Server 2012 R2 domains to control which hosts an account can sign-on from and apply access control conditions for authentication to services running as an account.
  • Authentication Policy Silos: New forest-based Active Directory object, which can create a relationship between user, managed service and computer, accounts to be used to classify accounts for authentication policies or for authentication isolation.

NTDSUTIL

This tool can remove old AD DC metadata which can stop the raising of Functional Levels

https://technet.microsoft.com/en-us/library/cc728068%28WS.10%29.aspx

ntdsutil

The GUI Metadata Cleanup Utility

The GUI Metadata Cleanup Utility removes Active Directory domain controller metadata left behind after a domain controller is removed improperly or unsuccessfully

https://gallery.technet.microsoft.com/scriptcenter/d31f091f-2642-4ede-9f97-0e1cc4d577f3

Forest Recovery Information

https://technet.microsoft.com/en-us/library/8e3e4377-ef54-4a70-9215-a5d2ba4d0eb9%28v=ws.10%29#BKMK_ResetTrustPassword

http://blogs.technet.com/b/askds/archive/2011/06/14/what-is-the-impact-of-upgrading-the-domain-or-forest-functional-level.aspx

Useful Microsoft Link

https://technet.microsoft.com/library/understanding-active-directory-functional-levels%28WS.10%29.aspx

Questions?

  • Once you have upgraded the Domain functional level, how long should you wait before upgrading the forest functional level?

The change should take effect immediately as soon as the operation completes on the server. if you have multiple DC’s or domain, it may take longer. If you have plenty of time and want to play it safe, wait 24 hours but normally 15 minutes is fine. if you have multiple DC’s, you can log into each DC and verify the functional level.

  • By raising the root domain functional level, will this automatically raise any child domains or do we need to raise the level on the PDC of the root domain then raise the level on the PDC in the child domain? Or do we do the child first then the root domain?

Each individual domain PDCe is responsible for maintaining it’s domain functional level.  Because of this, where you raise the domain functional level first, does not matter (parent domain or child domain).  Each domain’s DC’s will operate at the domain functional level of it’s PDCe (so long as it is supported).  The Forest Functional Level affects all domains.  As such all domains must be operating at or above the proposed Forest Functional Level.

  • What is the best way to recover if things don’t go to plan? For e.g With a root domain with 2 DCs and a child domain with 5 DCs?

Before Windows Server 2008 R2, the only ways to recover are rebuild or restore from backup.

As the PDCe is responsible for the Domain Functional Level and the Schema Operations Master is responsible for the Forest Functional Level, first, you would have to restore the server that holds the Schema Operations Master in the Parent domain (if you will be reverting to a Domain Functional Level less than allowed by the Forest Functional Level). Then you would restore the server that holds the PDCe FSMO role for each child domain.

  • If we are running at Windows 2000 native domain level with all Windows 2008 R2 servers, can we raise the domain functional level straight to Windows Server 2008 R2?

If all of your DC’s are running Windows Server 2008 R2 then yes.

Quest ActiveRoles Management Shell for Active Directory

April 3, 2013 Active Directory, PowerShell No comments

untitled

Quest ActiveRoles Management Shell for Active Directory

The ActiveRoles Management Shell for Active Directory is a set of predefined commands for Windows PowerShell, the new command line and scripting language developed by Microsoft. These commands are designed to help administrators automate common, repetitive and bulk management tasks such as creating, removing or updating objects in Active Directory.
By using the ActiveRoles Management Shell for Active Directory to build your scripts, you can harness Quest ActiveRoles Server to leverage proven rules, roles, workflow and attestation features giving you a robust management option for Windows PowerShell and Active Directory.

The management operations are performed either via the Quest ActiveRoles Server proxy service or by directly accessing directory data on domain controllers. In both cases, the ActiveRoles Management Shell provides a flexible scripting platform that can reduce the complexity of current Microsoft Visual Basic scripts. Tasks that previously required many lines in Visual Basic scripts can now be done by using as little as one line of code in the ActiveRoles Management Shell.

Installing the ActiveRoles Management Shell

q1

q2

q3

q4

q5

Opening the ActiveRoles Management Shell

You can open the ActiveRoles Management Shell by using either of the
following procedures. Each procedure loads the ActiveRoles Management Shell
snap-in into Windows PowerShell. If you do not load the ActiveRoles
Management Shell snap-in before you run a command (cmdlet) provided by
that snap-in, you will receive an error.

To open the ActiveRoles Management Shell from the Programs menu

  • Select Start | All Programs | Quest Software | ActiveRoles Management Shell for Active Directory.

To add the ActiveRoles Management Shell snap-in from Windows
PowerShell

  • Select Start | All Programs | Windows PowerShell 1.0 | Windows PowerShell.
  • At the Windows PowerShell prompt, enter the following command:
  • Add-PSSnapin Quest.ActiveRoles.ADManagement

Using the ActiveRoles Management Shell

  • Select Start | All Programs | Quest Software | ActiveRoles Management Shell for Active Directory.

q0

Admin Guide

Quest ActiveRoles Management Shell Admin Guide

Example Command to check for inactive users in Active Directory

get-qaduser -SizeLimit 0 | Where-Object{$_.LastLogon -lt $limit -OR $lastLogon -ne $null} | Sort-Object LastLogon | Select-Object Name, SAMAccountName, LastLogon | Export-CSV C:\PATH\TO\file.csv

 

VBScript to get Active Directory User Logon Information, Disable and Move

January 22, 2013 Active Directory No comments

vb

What does this VBScript script do?

  • Checks all accounts to determine what needs to be disabled.
  • If LastLogonTimeStamp is Null and object is older than specified date, it is disabled and moved.
  • If account has been used, but not within duration specified, it is disabled and moved.
  • If account is already disabled it is left where it is.

Please adjust the variables according to your AD and copy into a Notepad file with an extension of .vbs and run

  • ADVBScript_Script.vbs

‘===========================================================================
‘ Checks all accounts to determine what needs to be disabled.
‘ If LastLogonTimeStamp is Null and object is older than specified date, it is disabled and moved.
‘ If account has been used, but not within duration specified, it is disabled and moved.
‘ If account is already disabled it is left where it is.
‘ Created 23/7/09 by Grant Brunton
‘===========================================================================

‘===========================================================================
‘ BEGIN USER VARIABLES
‘===========================================================================

‘ * Change this to your domain *
‘DSEroot=”DC=domain,DC=local”

‘ Flag to enable the disabling and moving of unused accounts
‘ 1 – Will Disable and move accounts
‘ 0 – Will create ouput log only
bDisable=0

‘ Number of days before an account is deemed inactive
‘ Accounts that haven’t been logged in for this amount of days are selected
iLogonDays=30

‘ LDAP Location of OUs to search for accounts
‘ LDAP location format eg: “OU=Users,OU=Test”
strSearchOU=”OU=Users”

‘ Search depth to find users
‘ Use “OneLevel” for the specified OU only or “Subtree” to search all child OUs as well.
strSearchDepth=”OneLevel”

‘ Location of new OU to move disabled user accounts to
‘ eg: “OU=Disabled Users,OU=Test”
strNewOU=”OU=_Disabled”

‘ Log file path (include trailing \ )
‘ Use either full directory path or relational to script directory
strLogPath=”.\logs\”

‘ Error log file name prefix (tab delimited text file. Name will be appended with date and .err extension)
strErrorLog=”DisabledAccounts_”

‘ Output log file name prefix (tab delimited text file. Name will be appended with date and .log extension)
strOutputLog=”DisabledAccounts_”

‘===========================================================================
‘ END USER VARIABLES
‘===========================================================================

‘===========================================================================
‘ MAIN CODE BEGINS
‘===========================================================================
sDate = Year(Now()) & Right(“0” & Month(Now()), 2) & Right(“0” & Day(Now()), 2)
Set oFSO=CreateObject(“Scripting.FileSystemObject”)
If Not oFSO.FolderExists(strLogPath) Then CreateFolder(strLogPath)
Set output=oFSO.CreateTextFile(strLogPath & strOutputLog & sDate & “.log”)
Set errlog=oFSO.CreateTextFile(strLogPath & strErrorLog & sDate & “.err”)
output.WriteLine “Sam Account Name” &amp;vbTab&amp; “LDAP Path” &amp;vbTab&amp; “Last Logon Date” &amp;vbTab&amp; “Date Created” &amp;vbTab&amp; “Home Directory”
errlog.WriteLine “Sam Account Name” &amp;vbTab&amp; “LDAP Path” &amp;vbTab&amp; “Problem” &amp;vbTab&amp; “Error”

Set rootDSE = GetObject(“LDAP://rootDSE”)
Set objConnection = CreateObject(“ADODB.Connection”)
objConnection.Open “Provider=ADsDSOObject;”
Set ObjCommand = CreateObject(“ADODB.Command”)
ObjCommand.ActiveConnection = objConnection
ObjCommand.Properties(“Page Size”) = 10
DSEroot=rootDSE.Get(“DefaultNamingContext”)

Set objNewOU = GetObject(“LDAP://” & strNewOU & “,” & DSEroot)
ObjCommand.CommandText = “<ldap: “=”” &=”” strsearchou=”” “,”=”” dseroot=””>;(&(objectClass=User)(objectcategory=Person));adspath;” & strSearchDepth

msgbox “<ldap: “=”” &=”” strsearchou=”” “,”=”” dseroot=””>;(&(objectClass=User)(objectcategory=Person));adspath;” & strSearchDepth

Set objRecordset = ObjCommand.Execute

On Error Resume Next

While Not objRecordset.EOF
LastLogon = Null
intLogonTime = Null

Set objUser=GetObject(objRecordset.fields(“adspath”))

If DateDiff(“d”,objUser.WhenCreated,Now) > iLogonDays Then
Set objLogon=objUser.Get(“lastlogontimestamp”)
If Err.Number &lt;&gt; 0 Then
WriteError objUser, “Get LastLogon Failed”
DisableAccount objUser, “Never”
Else
intLogonTime = objLogon.HighPart * (2^32) + objLogon.LowPart
intLogonTime = intLogonTime / (60 * 10000000)
intLogonTime = intLogonTime / 1440
LastLogon=intLogonTime+#1/1/1601#

If DateDiff(“d”,LastLogon,Now) > iLogonDays Then
DisableAccount objUser, LastLogon
End If
End If
End If
WriteError objUser, “Unknown Error”
objRecordset.MoveNext
Wend
‘===========================================================================
‘ MAIN CODE ENDS
‘===========================================================================

‘===========================================================================
‘ SUBROUTINES
‘===========================================================================
Sub CreateFolder( strPath )
If Not oFSO.FolderExists( oFSO.GetParentFolderName(strPath) ) Then Call CreateFolder( oFSO.GetParentFolderName(strPath) )
oFSO.CreateFolder( strPath )
End Sub

Sub DisableAccount( objUser, lastLogon )
On Error Resume Next
If bDisable <> 0 Then
If objUser.accountdisabled=False Then
objUser.accountdisabled=True
objUser.SetInfo
WriteError objUser, “Disable Account Failed”
objNewOU.MoveHere objUser.adspath, “CN=”&amp;objUser.CN
WriteError objUser, “Account Move Failed”
Else
Err.Raise 1,,”Account already disabled. User not moved.”
WriteError objUser, “Disable Account Failed”
End If
End If
output.WriteLine objUser.samaccountname &vbTab& objUser.adspath &vbTab& lastLogon &vbTab& objUser.whencreated &vbTab& objUser.homedirectory
End Sub

Sub WriteError( objUser, strProblem )
If Err.Number &lt;&gt; 0 Then
errlog.WriteLine objUser.samaccountname &vbTab& objUser.adspath &vbTab& strProblem &vbTab& Replace(Err.Description,vbCrlf,””)
Err.Clear
End If
End Sub

‘===========================================================================
‘ END SUBROUTINES
‘===========================================================================

Powershell Script to get Active Directory User Logon Information

January 22, 2013 Active Directory, PowerShell No comments

PowerShell

To get the last logon Date/Time of Users in AD

$Domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$ADSearch = New-Object System.DirectoryServices.DirectorySearcher
$ADSearch.PageSize = 100
$ADSearch.SearchScope = “subtree”
$ADSearch.SearchRoot = “LDAP://$Domain”
$ADSearch.Filter = “(objectClass=user)”
$ADSearch.PropertiesToLoad.Add(“distinguishedName”)
$ADSearch.PropertiesToLoad.Add(“sAMAccountName”)
$ADSearch.PropertiesToLoad.Add(“lastLogonTimeStamp”)
$userObjects = $ADSearch.FindAll()

foreach ($user in $userObjects)
{
$dn = $user.Properties.Item(“distinguishedName”)
$sam = $user.Properties.Item(“sAMAccountName”)
$logon = $user.Properties.Item(“lastLogonTimeStamp”)
if($logon.Count -eq 0)
{
$lastLogon = “Never”
}
else
{
$lastLogon = [DateTime]$logon[0]
$lastLogon = $lastLogon.AddYears(1600)
}

“””$dn””,$sam,$lastLogon”
}

Script explained by David Hoelzer

Many Thanks for this excellent explanation

Scripting Video

 

Fine Grained Password Policy Example

December 4, 2012 Active Directory, microsoft No comments

Introduction

One of the nice features introduced in Windows Server 2008R2 AD DS is the ability to configure fine grained password policies through GUI.. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain

Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of User objects) and Global Security Groups. They cannot be applied to Computer objects.

Instructions

  • Log into your DC and type Start > Run > gpmc.msc or Start > Administrative Tools > Group Policy Management
  • Expand Forest: yourforest.com.
  • Expand Domains: yourdomain.com.
  • Click Default Domain Policy and Click Settings in the right hand pane
  • Check the current Password Policy

  • When you have finished noting the settings you currently have you can minimise the Group Policy Console
  • Next type Start > Run > adsiedit.msc
  • Right-click on ADSIEdit > connect to:

  • Click OK
  • Expand to Default Naming content > DC=yourdomain,DC=com\CN=System\CN=Password Settings Container\

  • Right-Click Password Settings Container and click New > Object.

  • Select msDS-PasswordSettings > Next

  • Type a Value such as NewPasswordPolicy > Next

  • This box msDS-PasswordsSettingsPrecedence as you can see above is an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object. If you have multiple PSOs, the PSO with the lowest priority takes precedence. Try typing 10 > Next

  • Type False for the box above msDS-PasswordReversibleEncryptionEnabled > Next

  • Type 24 for msDS-PasswordHistoryLength to stop people keeping the same password for 2 years (24 months) > Next

  • Type True for msDS-PasswordComplexityEnabled to allow complexity of Caps, Lower Case, Numbers and Special Characters > Next

  •  Type 8 for msDS-MinimumPasswordLength for the minimum characters a password can be > Next
  • Now we get into the next section of configuration where different rules apply.
  • When you use ADSI Edit to create the following Password Settings objects (PSOs), enter the values of the four time-related PSO attributes (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow, and msDS-LockoutDuration) in d:hh:mm:ss format.
  • Please see this link for detailed settings
  • http://technet.microsoft.com/en-us/library/cc754461.aspx

  • Type 1:00:00:00 for msDS-MinimumPasswordAge for a 1 day age of password before a user can change it > Next

  • Type 42 for msDS-MaximumPasswordAge. This will set 42 days before a user is prompted to change their Password > Next

  • Type 10 for the amount of Password Attempts that are made before the account is locked out > Next

  • Type 30 for msDS-LockoutObservationWindow. This setting specifies how long the system should collect bad password attempts to compare to the msDS-LockoutThreshold value. The Lockout Observation window must be smaller than or equal to the lockout duration for a password policy

  • Type 0:00:30:00 for msDS-LockoutDuration to set a 30 minute account lockout duration. The lockout duration must be greater than or equal to the lockout observation time for a password policy > Next

  • You can either click Finish or Click on More Attributes

  • Select Both for Select which Properties to View
  • Click the Drop down on Select a Property to View and choose msDS-PSOAppliesTo
  • Click Edit Attribute

  • In Edit Attribute, add the distinguished names of users or global security groups that the PSO is to be applied to, and then click Add. E.g CN=Users,DC=testdomain,DC=Local
  • You are all Complete with a separate Password Policy applied to a subset of your Active Directory

Link to Step by Step Guide

http://technet.microsoft.com/en-us/library/cc770842.aspx

Understanding FSMO Roles in Server 2008

November 21, 2012 Active Directory No comments

There are five of these FSMO roles in every forest. They are:

  • Schema Master
  • Domain Naming Master
  • Infrastructure Master
  • Relative ID (RID) Master
  • Primary Domain Controller (PDC) Emulator

Two of them are only assigned once in the forest, in the domain at the forest root.

  • Schema Master
  • Domain Naming Master

Three of those FSMO roles are needed once in every domain in the forest:

  • Infrastructure Master
  • Relative ID (RID) Master
  • Primary Domain Controller (PDC) Emulator

Schema Master

Whenever the schema is modified at all, those updates are always completed by the domain controller with the schema master role.  Schema is updated during the normal replication, and the schema updates are replicated throughout all the domains in the forest. It’s advisable to place the schema master role on the same domain controller (DC) as the primary domain controller (PDC) emulator.

Domain Naming Master

This role is not used very often, only when you add/remove any domain controllers. This role ensures that there is a unique name of domain controllers in environments as domains join or leave the forest, the domain naming master makes the updates into active directory.  Only this DC actually commits those changes into the directory.  The domain naming master also commits the changes to application partitions.

Infrastructure Master

This role checks domain for changes to any objects. If any changes are found then it will replicate to another domain controller. The infrastructure master is a translator, between globally unique identifiers (GUIDs), security identifiers (SIDs), and distinguished names (DNs) for foreign domain objects.  If you’ve ever looked at group memberships of a domain local group which has members from other domains, you can sometimes see those users and groups from the other domain listed only by their SID.  The infrastructure master of the domain of which those accounts are in is responsible for translating those from a SID into their name

Usually, you do not put the infrastructure master role on a domain that holds the global catalog.  However, if you’re in a single domain forest, the infrastructure master has no work to do, since there is no translation of foreign principals

Relative ID (RID) Master

This role is responsible for making sure each security principle has a different identifier. The relative ID master, or RID master, hands out batches of relative IDs to individual domain controllers, then each domain controller can use their allotment to create new users, groups, and computers.  When domain controllers need more relative IDs in reserve, they request them from, and are assigned by, the domain controller with the RID master FSMO role.

It is recommended that the RID master FSMO role be assigned to whichever domain controller has the PDC emulator FSMO role

PDC Emulator

The domain controller that has the PDC emulator FSMO role assigned to it has many duties and responsibilities in the domain.  For example, the DC with the PDC emulator role is the DC that updates passwords for users and computers.  When a user attempts to login, and enters a bad password, it’s the DC with the PDC emulator FSMO role that is consulted to determine if the password has been changed without the replica DC’s knowledge. The PDC emulator is also the default domain controller for many administrative tools, and is likewise the default DC used when Group Policies are updated.

Additionally, it’s the PDC emulator which maintains the accurate time that the domain is regulated by.  It’s the time on the PDC emulator which identifies when the last write time for an object was (to resolve conflicts, for example.)  If it’s a forest with multiple domains, then the forest root PDC is the authoritative time source for all domains in the forest.

Each domain in the forest needs its own PDC emulator. Ideally, you put the PDC emulator on the domain controller with the best hardware available.

Seizing of Roles

In case of failures of any server you need to seize the roles. Administrators should use extreme caution in seizing FSMO roles. This operation, in most cases, should be performed only if the original FSMO role owner will not be brought back into the environment.

It is recommended that you log on to the domain controller that you are assigning FSMO roles to. The logged-on user should be a member of the Enterprise Administrators group to transfer schema or domain naming master roles, or a member of the Domain Administrators group of the domain where the PDC emulator, RID master and the Infrastructure master roles are being transferred.

For Schema Master:

  1. Go to cmd prompt and type ntdsutil
  2. Type roles and press enter to enter fsmo maintenance.
  3. To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ? and then press Enter
  4. Type connections to enter server connections.
  5. Type connect to server “Servername” and then press ENTER, where “Servername” is the name of the domain controller you want to assign the FSMO role to
  6. Type quit
  7. Type seize schema master. For a list of roles that you can seize, type ? at the fsmo maintenance prompt, and then press ENTER, or see the list of roles at the start of this article

After you have seized the role, type quit to exit NTDSUtil.

For Domain Naming Master:

Go to cmd prompt and type ntdsutil

  1. Go to cmd prompt and type ntdsutil
  2. Type roles and press enter to enter fsmo maintenance.
  3. To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ? and then press Enter
  4. Type connections to enter server connections.
  5. Type connect to server “Servername” and then press ENTER, where “Servername” is the name of the domain controller you want to assign the FSMO role to
  6. Type quit
  7. Type seize domain naming master.

After you have Seize the role, type quit to exit NTDSUtil.

For Infrastructure Master Role:

Go to cmd prompt and type ntdsutil

  1. Go to cmd prompt and type ntdsutil
  2. Type roles and press enter to enter fsmo maintenance.
  3. To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ? and then press Enter
  4. Type connections to enter server connections.
  5. Type connect to server “Servername” and then press ENTER, where “Servername” is the name of the domain controller you want to assign the FSMO role to
  6. Type quit
  7. Type seize infrastructure master.

After you have Seize the role, type quit to exit NTDSUtil.

For RID Master Role:

Go to cmd prompt and type ntdsutil

  1. Go to cmd prompt and type ntdsutil
  2. Type roles and press enter to enter fsmo maintenance.
  3. To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ? and then press Enter
  4. Type connections to enter server connections.
  5. Type connect to server “Servername” and then press ENTER, where “Servername” is the name of the domain controller you want to assign the FSMO role to
  6. Type quit
  7. Type seize RID master.

After you have Seize the role, type quit to exit NTDSUtil.

For PDC Emulator Role:

Go to cmd prompt and type ntdsutil

  1. Go to cmd prompt and type ntdsutil
  2. Type roles and press enter to enter fsmo maintenance.
  3. To see a list of available commands at any one of the prompts in the Ntdsutil utility, type ? and then press Enter
  4. Type connections to enter server connections.
  5. Type connect to server “Servername” and then press ENTER, where “Servername” is the name of the domain controller you want to assign the FSMO role to
  6. Type quit
  7. Type seize PDC.

After you have Seize the role, type quit to exit NTDSUtil

How can I determine who are the current FSMO Roles holders in my domain/forest?

  • On any domain controller, click Start, click Run, type ntdsutil in the Open box, and then click OK.

The FSMO role holders can be easily found by use of some of the AD snap-ins. Use this table to see which tool can be used for what FSMO role: